How to make Meteor unignore package.json#imports inside dependencies?

digitalextremist · November 2, 2024, 3:21am

In the course of my agent / server / client design pattern shift I want to remove console.log and go for isomorphic ( where appropriate ) asynchronous sequential Logger from day 0; but for today, I just put in a wrapper, and focus on the portability portion, to at least cover both agent and server for now.

matrix-bot-sdk has a logger already in use in at least one agent being ported ( which makes for a CLI by chat, and real-time interaction with the entire distributed application ) and it wisely and practically uses chalk because digital adulting does demands color in console logs… but… chalk uses package.json#imports like so:

github.com

chalk/chalk/blob/4a10354857ba6d7932dad5fa6ef2e021c4ed47fb/source/index.js#L1-L2


      
          import ansiStyles from '#ansi-styles';
          import supportsColor from '#supports-color';

Which is defined here:

github.com

chalk/chalk/blob/4a10354857ba6d7932dad5fa6ef2e021c4ed47fb/package.json#L11-L16


      
          	"imports": {
          		"#ansi-styles": "./source/vendor/ansi-styles/index.js",
          		"#supports-color": {
          			"node": "./source/vendor/supports-color/index.js",
          			"default": "./source/vendor/supports-color/browser.js"
          		}

And I already pretty much complained about here, but not the package.json#imports approach:

Now rather than having 3 places where I define path aliases I want to be more like chalk when I grow up, and use package.json#imports … BUT, then I see this, which might be on the Vite side ( @jorgenvatle ) and not Meteor proper:

Unable to resolve some modules:

  "#ansi-styles" in
/archive/01E/zero/code/ETC/decentrality/node_modules/chalk/source/index.js
(os.linux.x86_64)
  "#supports-color" in
/archive/01E/zero/code/ETC/decentrality/node_modules/chalk/source/index.js
(os.linux.x86_64)

If you notice problems related to these missing modules, consider running:

  meteor npm install --save #ansi-styles #supports-color

Notice how the suggestion would also not fix it, short of forking chalk and removing # from each and including the packages as dependencies ( which do exist on their own also )

Since I do not want to reference matrix-bot-sdk just to get its logger, I extracted and adapted the logger, but chalk itself is what introduces this package.json#imports issue.

Is there a known convention to get Meteor to respect package.json#imports for super vital things like chalk which one ought not be forced to forego in this life?

It does seem like there is discussion in the neighborhood of this issue in node itself which ought do the import based on the package.json but which Meteor has wrapped and taken charge of in meteor-tool …

github.com/nodejs/node

Relax package.json#imports prefix

opened 02:53PM - 15 Aug 23 UTC

closed 01:26AM - 29 Jun 24 UTC

bmeck

module feature request esm stale

### What is the problem this feature will solve? Tools such as rspack, bun, t…ypescript, remix, and turbo are all looking at using tsconfig.json#compilerOptions.paths . This is in part due to constraints on package.json#imports and it lacking the ability to fully alias the entire import space. These also seem to have differing constraints and some are doing something outside the standard TS behavior on purpose. ### What is the feature you are proposing to solve the problem? The `package.json#imports` field seems sufficient from reading some twitter threads involving a few maintainers from remix or rspack except for the prefix `#` constraint. I propose getting feedback from these tools on removing the constraint if that would be sufficient for their users’ general needs. If it is sufficient we could encourage people to use a single way of doing this allowing tooling to avoid divergence and interop woes. This would not cover global aliasing which already can be covered with policy redirects but likely is not desirable/sufficient for some subset of users. My hope is that subset is small enough to avoid the issue blocking this entirely. ### What alternatives have you considered? Supporting tsconfig.json in a limited subset to alleviate the user needs. cc @nodejs/loaders @nodejs/modules

Going to root around a bit to see if there are tsconfig.json or vite.config.ts or .babelrc settings, but you see my problem now. Although I have plenty of hair still at the front end of “40” I would not pull any out over path aliases, whether for myself, or for downstream dependencies we all know and love. Like chalk!

digitalextremist · November 2, 2024, 3:34am

This looks like Vite to start with, and my exact example is given in the comments:

github.com/vitejs/vite

Support ESM-style `"imports"` field aliases in `package.json`

opened 08:41AM - 20 Mar 22 UTC

closed 03:47PM - 06 Mar 23 UTC

lehni

enhancement

### Clear and concise description of the problem As of v14, Node.js now suppo…rts defining aliases for ESM imports in the `packages.json` through the `"imports"` field. Vite supports rollup-style aliases. It would be nice if Vite was capable out of the box of reading the `"imports"` field and translating it correctly to rollup aliases. ### Suggested solution As a proof of concept, I have implemented a version that uses rollup's `customResolver` feature and works as long as no conditional imports are used. It turned out to be surprisingly simple: ```js import path from 'path' import fs from 'fs' import { defineConfig } from 'vite' import { findUpSync } from 'find-up' const pkg = findUpSync('package.json', { cwd: process.cwd() }) const { imports = {} } = JSON.parse(fs.readFileSync(pkg, 'utf8')) export default defineConfig({ // ... resolve: { alias: [ { // Use a custom rollup resolver to emulate ESM-style imports // mappings in vite, as read from `package.json` above: find: /^#/, replacement: '#', customResolver(id) { for (const [find, replacement] of Object.entries(imports)) { const { match, capture } = matchIdentifier(id, find) if (match) { const replacementPath = path.resolve(replacement) id = capture ? replacementPath.replace('*', capture) : replacementPath } } return id } } ] } }) function matchIdentifier(id, pattern) { const regexp = new RegExp(`^${pattern.replace('*', '(.*)')}$`) const match = id.match(regexp) return { match: !!match, capture: match?.[1] } } ``` This works for my code-base with the following imports map: ```json "imports": { "#config": "./src/config/index.js", "#app": "./src/server/app.js", "#models": "./src/server/models/index.js", "#models/*": "./src/server/models/*.js", "#controllers": "./src/server/controllers/index.js", "#controllers/*": "./src/server/controllers/*.js", "#services": "./src/server/services/index.js", "#services/*": "./src/server/services/*.js", "#errors": "./src/server/errors/index.js", "#utils": "./src/server/utils/index.js", "#utils/*": "./src/server/utils/*.js", "#features/*": "./src/server/features/*.js", "#admin/schema": "./src/admin/schema/index.js", "#admin/*": "./src/admin/*.js", "#test/*": "./test/*.js" } ``` It shouldn't be too hard to expand this to also support conditional imports. ### Alternative _No response_ ### Additional context _No response_ ### Validations - [X] Follow our [Code of Conduct](https://github.com/vitejs/vite/blob/main/CODE_OF_CONDUCT.md) - [X] Read the [Contributing Guidelines](https://github.com/vitejs/vite/blob/main/CONTRIBUTING.md). - [X] Read the [docs](https://vitejs.dev/guide). - [X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Will work through the Vite portion then double-check at container build also.

digitalextremist · November 2, 2024, 3:36am

Looks like the official term is subpath imports Modules: Packages | Node.js v23.1.0 Documentation

digitalextremist · November 2, 2024, 4:03am

Seeing chalk brought up a lot and curious now, but this seems Vite specific until I can verify otherwise, so I am tracking here:

github.com/JorgenVatle/meteor-vite

Does meteor-vite ignore package.json#imports by default, or is meteor-tool trimming wings?

opened 03:25AM - 02 Nov 24 UTC

digitalextremist

Notes here: https://forums.meteor.com/t/how-to-make-meteor-unignore-package-json…-imports-inside-dependencies/62493/1 `package.json#imports` seems ignored in at least one case, but in looking at that convention... wow would I love to use that instead of setting aliases in three places. Thought to ask the solo ninja wizard around here while pursuing this. Please let me know if there is a better place for issues which start out as questions but might turn into items to resolve if there is a problem.

digitalextremist · November 5, 2024, 4:22pm

This has been an insane trip. Had to disable chalk but now having similar issues in the course of:

… with my own packages, because of the multi-builder issue versus shifting design to build potentially infinite agents same as with server and client entry points.

Right now I have 4 agents, and I feel like the import issues and two package systems and all that is going to be the straw that breaks the camel’s back on paradigm shifting.

At a certain point you ask “do I want it to work, or do I want this approach to work” and Meteor is feeling like technical debt on that point. But, giving myself until next Summer to “pivot or persevere” on that front.

digitalextremist · November 9, 2024, 12:56am

Have not tried chalk again but have been using subpath imports myself, within the repository versus in a dependency ( which seems like the actual issue, subpath imports work fine, it is distantly related sub-sub-dependency subpath imports that are a pain ) … But it seems like I would just switch to a fork and remove that issue versus fuss with something ultra-minor which seems to be a stone in the shoe of a LOT of coders, and most of them citing chalk ( or Angular but less so, compared to chalk ) …

So I am going to call this solved and abandon, because in this case it is a fool’s errand to try to resolve this just to get colored console logs ( when I can fork and use an easily resolved reference ) since this is a “world pain” versus something solvable and stable. Solution is to recognize the problem and let it go, then circle back when it becomes valuable. For now, it is such a minor area that even if my fork went out of sync for years, I would likely feel no pain and no desire to get up to speed again. And using multi-entrypoint builds beyond client and server will be dismantling the code-space anyway and reflowing everything at the foundation, so this will be reapproached much more directly there, in import strategy between infinite possible applications sharing one environment.