-
Notifications
You must be signed in to change notification settings - Fork 235
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix monorepo support by allowing import to do what it's good at (and … #2359
Fix monorepo support by allowing import to do what it's good at (and … #2359
Conversation
let plugin; | ||
|
||
try { | ||
let importedModule = await import(pluginName); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without trying this first, we can't actually use plugins from node_modules
🙈
For example, prior to this change, we'd get this error:
<repo>/node_modules/resolve/lib/sync.js:102
var err = new Error("Cannot find module '" + x + "' from '" + parent + "'");
^
Error: Cannot find module 'ember-template-lint-plugin-tailwindcss' from '<repo>/frontend'
at Function.resolveSync [as sync] (<repo>/node_modules/resolve/lib/sync.js:102:15)
at requirePlugin (file://<repo>/node_modules/ember-template-lint/lib/get-config.js:31:28)
at processPlugins (file://<repo>/node_modules/ember-template-lint/lib/get-config.js:150:22)
at getProjectConfig (file://<repo>/node_modules/ember-template-lint/lib/get-config.js:396:28)
at async Linter.loadConfig (file://<repo>/node_modules/ember-template-lint/lib/linter.js:48:19)
at async Linter.verify (file://<repo>/node_modules/ember-template-lint/lib/linter.js:304:7)
at async run (file://<repo>/node_modules/ember-template-lint/bin/ember-template-lint.js:211:21) {
code: 'MODULE_NOT_FOUND'
}
error Command failed with exit code 1. }
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain more about how the monorepo is setup?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue is present in any monorepo where the ember project is not at the root, where the root's node_modules contains ember-template-lint (so almost every monorepo)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the reproduction is very easy:
- clone any monorepo
- cd into the monorepo
- cd into the ember project
- swap out template lint for v4
- add a template-lint plugin that is compat with v4
- error
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you suggesting that your monorepo has ember-template-lint
in the root (presumably as a devDep), and the plugins in subdirs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't say typically. If you have a small enough monorepo where you can have the same version of a tool everywhere and every package in the monorepo needed it, it may make sense.
But monorepo conventions are orthogonal to the issue here 🙃
It's perfectly reasonable for only one package in a monorepo to need template lint, and therefor, it'd be local to that package, yet potentially still hoisted
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK sure. I suppose from my perspective that's part of the benefit of monorepos - minimizing tool dependencies so you have less maintenance. But of course that's not super relevant, though what I was getting at was trying to first determine if this was an issue that could be handled via a recommended setup vs. a code change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
makes sense -- important question though -- why were we not relying on the built-in node resolution algo (which happens for us via import
/require
) and trying to find deps ourselves?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why were we not relying on the built-in node resolution algo (which happens for us via import/require) and trying to find deps ourselves?
Because the node resolution algorithm is actually wrong in this case 😸. We don't want to resolve the plugin name relative to ember-template-lint
. Specifically, the node modules algorithm would suggest that the plugin must be resolvable from whatever location ember-template-lint
itself is installed at. Which is not correct! The plugin will be installed somewhere relative to the .template-lintrc.js
file not where ever** ember-template-lint
happens to be installed. This is the point of the current resolve.sync
code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I disagree. And in the mean time, all plugin usage is broken in monorepos 😢
We'll need tests for this that fail before the change and pass after. |
How do you want that to happen? |
@NullVoxPopuli yes we have tests / test fixtures that set up fake projects and plugins. We will need to do something similar for this monorepo situation. |
@bmish I've added the beginnings of a test, the main thing is that I need to set the baseDir of a |
@bmish anyway to move forward without the test? or is there some other way to simulate monorepo? I suppose I could not use fixturify-project for the monorepo test 🤔 This is just blocking adoption within all monorepos 🙃 imo, letting node do the module resolution by default (instead of via file path) is the more correct thing to do anyway 🥳 |
Having tests for all changes is very important to me, especially for a change like this. I made sure all the changes that went into the v4 release were comprehensively tested. So it will be great for us to get this monorepo scenario tested. I can try to help with the |
I'm with ya there -- especially with big projects. I don't think I want to deal with fixturify changes 🙃 |
My preferred path is that we get the |
Tests for this should hopefully be unblocked now that this has been merged: |
a519171
to
9df7849
Compare
Taking another crack at this over in #2471 |
More tests being added in #2473 |
At the moment, I'm not able to reproduce a failure (in either #2471 or #2473). I think we need a better understanding of the failure (preferably via a reproduction in the "clone this, npm install, npm test" form) that @NullVoxPopuli was trying to fix. |
full repro steps: Terminal 1 git clone git@github.com:NullVoxPopuli/limber.git
cd limber
git checkout etl-repro
yarn This branch, Below is where we get the ESM version of the plugin, as plugins gotta be ESM Terminal 2 git@gitlab.com:NullVoxPopuli/ember-template-lint-plugin-tailwindcss.git
cd ember-template-lint-plugin-tailwindcss
git checkout vitest
yarn
yarn build
yarn link Back in Terminal 1 yarn link ember-template-lint-plugin-tailwindcss
cd frontend
yarn link ember-template-lint-plugin-tailwindcss
yarn lint:hbs Expected Error:
|
Thank you @NullVoxPopuli! Finally reproduced this style of failure over in #2475. The good news is that it is specifically limited to cases where |
I missed this. This doesn't seem as bad as i thought |
…ignoring paths 🙃)