Provide npm-friendly settings.json

theetrain commented 4 months ago

The problem

Currently, modules configured in project.inlang/settings.json are served via a CDN like this:

{
  "$schema": "https://inlang.com/schema/project-settings",
  "sourceLanguageTag": "en",
  "languageTags": ["en"],
  "modules": [
    "https://cdn.jsdelivr.net/npm/@inlang/message-lint-rule-empty-pattern@latest/dist/index.js",
    "https://cdn.jsdelivr.net/npm/@inlang/message-lint-rule-missing-translation@latest/dist/index.js",
    "https://cdn.jsdelivr.net/npm/@inlang/message-lint-rule-without-source@latest/dist/index.js",
    "https://cdn.jsdelivr.net/npm/@inlang/message-lint-rule-valid-js-identifier@latest/dist/index.js",
    "https://cdn.jsdelivr.net/npm/@inlang/plugin-message-format@latest/dist/index.js",
    "https://cdn.jsdelivr.net/npm/@inlang/plugin-m-function-matcher@latest/dist/index.js"
  ],
  "plugin.inlang.messageFormat": {
    "pathPattern": "./languages/{languageTag}.json"
  }
}

I understand the rationale is to allow modules to run completely browser-side in order to support tools such as Fink, and to be bundler-agnostic. However, my team leverages dependabot and socket.dev for managing "approved" modules, upgrades, and vulnerability scanning. As it stands, the above settings bypasses that process.

Proposal

Please allow browser tools such as Fink to operate in some manner that would allow modules to be installed and trackable with npm CLI flows such as dependabot. Perhaps an opt-in build step could make this work, but I understand the trade-off there may require support for multiple bundlers.

Alternatives

1. Use `node_modules` paths for inlang modules

My current workaround is to install the above modules in my project's devDependencies, and adjust the module paths in settings.json; but the trade-off is Fink won't be able to run browser-side:

{
  "$schema": "https://inlang.com/schema/project-settings",
  "sourceLanguageTag": "en",
  "languageTags": ["en"],
  "modules": [
-   "https://cdn.jsdelivr.net/npm/@inlang/message-lint-rule-empty-pattern@latest/dist/index.js",
-   "https://cdn.jsdelivr.net/npm/@inlang/message-lint-rule-missing-translation@latest/dist/index.js",
-   "https://cdn.jsdelivr.net/npm/@inlang/message-lint-rule-without-source@latest/dist/index.js",
-   "https://cdn.jsdelivr.net/npm/@inlang/message-lint-rule-valid-js-identifier@latest/dist/index.js",
-   "https://cdn.jsdelivr.net/npm/@inlang/plugin-message-format@latest/dist/index.js",
-   "https://cdn.jsdelivr.net/npm/@inlang/plugin-m-function-matcher@latest/dist/index.js"
+   "node_modules/@inlang/message-lint-rule-empty-pattern/dist/index.js",
+   "node_modules/@inlang/message-lint-rule-missing-translation/dist/index.js",
+   "node_modules/@inlang/message-lint-rule-without-source/dist/index.js",
+   "node_modules/@inlang/message-lint-rule-valid-js-identifier/dist/index.js",
+   "node_modules/@inlang/plugin-message-format/dist/index.js",
+   "node_modules/@inlang/plugin-m-function-matcher/dist/index.js"
  ],
  "plugin.inlang.messageFormat": {
    "pathPattern": "./languages/{languageTag}.json"
  }
}

2. Lock jsdelivr versions

We could alternatively lock inlang modules served by jsdelvr to a specific version, or specific major such as:

-   "https://cdn.jsdelivr.net/npm/@inlang/plugin-m-function-matcher@latest/dist/index.js"
+   "https://cdn.jsdelivr.net/npm/@inlang/plugin-m-function-matcher@0.9/dist/index.js"

Though the above would allow Fink to run browser-side, this would require manual tracking and upgrades.

Other notes

A related issue is these packages run a postinstall script patch-package (example) that feels redundant for my project, and perhaps for this consumption pattern. If there's a way to remove that requirement, I'd appreciate it. For now, I've installed patch-package as part of my project's devDependencies in order to also install inlang modules.

samuelstroschein commented 4 months ago

@theetrain thanks for the elaborate issue. Do you agree with the following:

You are not asking for an NPM friendly "dependency management" but "a dependency management" system in general.

If you are making the proposal for dependency management of inlang modules, I am on your side. Locking versions, caching of modules, trusted endpoints, etc. If you are asking, like your proposal is phrased right now, to leak NPM into inlang, I will push back:

NPM doesn't run in the browser
NPM is unusable by non-developers (translators, designers, etc.) need to be able to manage dependencies too
Inlang is stack agnositic. NPM is stack specific to the web world

If you agree that (general) dependency management would solve your issues, we can go ahead and draft a project that we put on the roadmap for the inlang SDK (which powers every app). If not, please elaborate what features you seek and why they can only be solved with NPM

theetrain commented 4 months ago

Thanks for making that clarification. Yes, I want modules to be manageable via npm; it would not be reasonable to force npm itself into Inlang workflows, as you've outlined. I want to manually install Inlang modules in my project's package.json.

Much like ESLint, so long as I am able to install Inlang modules via npm and perhaps import them in my Inlang settings, then I will be able to manage updates and scan for vulnerabilities for all my project's package.json dependencies.

samuelstroschein commented 4 months ago

I will be able to manage updates and scan for vulnerabilities for all my project's package.json dependencies.

Why would a CLI command for auditing inlang modules not be sufficient? You could run npm audit && inlang audit as part of your pipeline

theetrain commented 4 months ago

Unless I'm misunderstanding, npm audit only applies to packages listed in package.json. In the default/current Inlang workflow, packages such as @inlang/message-lint-rule-empty-pattern won't get audited since they're sourced via https://cdn.jsdelivr.net and are listed as strings in inlang.project/settings.json.

I'm only able to audit and manage @inlang/message-lint-rule-empty-pattern now that I've moved forward with "alternative 1" above. Sorry for causing back-and-forth, I hope this clears up my intentions.

You could run npm audit && inlang audit as part of your pipeline

I tried npx inlang audit just now, but it yielded an error. Is this feature documented somewhere?

samuelstroschein commented 4 months ago

inlang audit doesn't exist yet. But it sounds like a feature like inlang audit would fulfill your requirements?

I am asking because you seem to argue for NPM while I believe you are only asking for "proper" dependency management that we are better of (can only solve) with an inlang specific dependency management solution to:

make it work in the browser
usuable by non-devs
stay tech stack agnostic (ios, android, deno, node, etc)

samuelstroschein commented 1 month ago

Closing because stale

opral / inlang-sdk