With native CSS improving a lot, using something like SCSS is not really necessary. And we've always been writing native JS, what doesn't need any build support. For linting, we can just use GitHub Actions. So, we don't need to use Node.js during our builds anymore, and we can get rid of it in all of our projects, making builds more reliable and faster, while removing a host of dependencies from our toolchain.

• Remove Lombiq.VueJs (NOT Lombiq.VueJs.Resources, we keep that) from OSOCE, and deprecate its NuGet package. Release a latest version before that if necessary.
• Remove Lombiq.BaseTheme from OSOCE, and deprecate its NuGet package in favor of Lombiq.BaseTheme.Native.
  • ❌ Release a latest version before that if necessary. (it's not)
  • Tell about this deprecation in its Readme (perhaps move the old Sass-focused main readme into the deprecated project's directory, like we did with Lombiq.VueJs).
• Reimplement CSS and JS linting solely from GitHub Actions in LGHA (we already have markdown-lint there, use that in OSOCE too).
  • Use the respective tool's CLIs, or otherwise the easiest approach with the least dependencies.
  • If possible, keep the interface of the workflow in NE. However, the linters should not use NE. Also, make it so that linters lint all CSS, JS, MD files by default, and if you want that, then no configuration is necessary.
  • Linters should use the config we use in NE today. Config override should be possible from the given repo, with the linter's usual approach (config files and inline ignores). Ideally, it'd be possible to have the same config locally as well, for IDEs (like ESLint warnings showing up in VS).
  • The default config would be best to switch over from eslint-config-airbnb-base to eslint-config-airbnb-extended (due to eslint v9 support airbnb/javascript#2961).
  • Add CSS, JS, MD linting for all projects in OSOCE, from the build-and-test and build-and-test-windows workflows in place of the current asset-lint jobs. Remove such linter workflows from every submodule.
  • Include documentation on how to run linters locally if one desires to.
• Remove NE from OSOCE, and deprecate its NuGet package. Release a latest version before that if necessary. Also tell about this deprecation in its Readme.
• Switch NPM dependency management over to Library Manager. See notes here. In the Chart.js and Data Tables modules you can start from the issue/OSOE-1010-libman branch, since this migration there was mostly done. See the two diffs (Chart.js, Data Tables) for inspiration.
  • Change all projects to use LibMan. No package.json file should remain in OSOCE.
  • Reimplement ConstantFromJson (this is missing with a temporary workaround from Chart.js and Data Tables).
  • Reimplement Renovate NPM package updates for libman.json in our common default. This sample might just cover this; otherwise, we have cases for custom config like this in https://github.com/Lombiq/UI-Testing-Toolbox/blob/dev/renovate.json5.
  • During CI builds, the LibMan cache can be persisted both for performance (but that should be all but negligible, since it already only downloads the files we request) and reliability, see: Ability to have secondary providers aspnet/LibraryManager#806 (comment). Do we need this? Under Windows, it's under C:\Users\username\AppData\Local.librarymanager (not sure if we can access this in GHA). Don't know what this translates to under Linux: https://github.com/aspnet/LibraryManager/blob/c3b92e56fb6f5a2459def8fbac2c47835d836e26/src/LibraryManager/Cache/CacheService.cs#L46.
• The setup-node action in LGHA should accept a none value that skips any Node.js setup. Set this in OSOCE (but keep the default of installing the LTS version for now).
• Write a blog post on Orchard Dojo not just announcing, but also explaining this. Link it from the Readme of the deprecated projects, with notes telling that this is what we recommend instead. Mention that NE will remain as a usable project (just as VueJs), just not something that we'd maintain anymore. It'll keep working until Node v26 removes corepack next year (Update to Node.js v26 and figure out whether to keep using corepack (OSOE-1170) NodeJs-Extensions#154). However, at that point, we could just keep using Node 24 in the projects that must keep using NE, what will be supported until about April 2028 (that's when LTS ends, but I'd assume you'll still be able to install it, just as you can do today with ancient versions)

Lombiq.Npm.Targets remains, and thus the ability of our projects to use NPM packages, installed during .NET build automatically. However, this is not something that we'd utilize at this point.

Jira issue