-
-
Notifications
You must be signed in to change notification settings - Fork 6
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
Convert project to es modules #17
Conversation
f71aa21
to
bcc1e02
Compare
LGTM. Test failed on prettier version 2 which personally I want to drop the support. Not sure what people think, should we keep compatibility with prettier 2 or drop it? |
I would rather see this move forward than have optimal backwards compatibility to be honest. However I might be able to take a look on the weekend to see what it would take to specify both an |
The way I see it, we might need to add build step before publishing into npm registry. Similar to how trivago/melody handling support for commonjs and es module. OTOH, there's problem with plugin system. Here what the output when loading CommonJS
ES Module
Still can't figure it out what the actual problem are. |
That's a good catch, i'll investigate here, I think this probably has something to do with this export, whilst being valid I don't think it is correct. |
src/util/pluginUtil.js
Outdated
pluginPaths.forEach(pluginPath => { | ||
const loadedPlugin = tryLoadPlugin(pluginPath); | ||
if (loadedPlugin) { | ||
result.push(loadedPlugin); | ||
loadedPlugin.then(res => { | ||
result.push(res); | ||
}); | ||
} | ||
}); | ||
} |
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 think the problem is how plugin being loaded. I can't even make the plugin to be executed. The variable result
returning an empty array. Tried async/await
function and still no success.
Something like this and other variation doesn't seems to work.
return pluginPaths.map(async pluginPath => await tryLoadPlugin(pluginPath));
Split up #17. We added `vitest` as test runner. Now we can safely remove `jest` with consequence removing jest related feature from eslint.
Split up #17. We added `vitest` as test runner. Now we can safely remove `jest` with consequence removing jest related feature from eslint.
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've partially applied your changes into separate commit/pull request. All that left is actually rewrite into es module. Would you be able to rebase?
Some notes:
- revert changes to snapshot test file. rewriting should not modify actual test result.
- revert change on
flake.nix
, unrelated - add
.eslintcache
into.gitignore
Thank you.
I am going back over this with some proper attention to detail. Do you have a preference on using or avoiding default exports? edit: actually never mind, I am going to keep this as like-for-like as possible. Anything named will stay named, anything default will stay as default. |
I have preference to keep the changes to be as minimal as possible. Unfortunately your changes is not exactly compatible with existing plugin functionality as you can see from modified snapshot file. Regarding plugin system, I'm not sure if I want to keep this feature. The I haven't test it on my local machine (hopefully this weekend). |
I am just working on it now actually stand by for some updates to this branch. I think that is a valid suggestion to just scrap the plugin functionality or at least remove it for now, to perhaps add it in later if it is going to stall further development. Whilst the Out of curiosity what system are you using Twig for and does that come bundled with some custom Twig extensions that you want to include? Craft CMS docs for tagshttps://craftcms.com/docs/2.x/templating/switch.html |
I'm using twig with symfony framework. Didn't know about twig use case outside symfony framework ecosystem. Knowing this, I don't want to break existing functionality (atleast without offering some alternatives). For now I want to keep all features as-is. Extension/features I want to add in the future includes:
|
I would say the easiest way would be to just scrap the plugin utility and move to an approach where that functionality is built into the core |
I have updated the PR with an example of what this would look like without the plugin feature and the switch tag print just rolled directly into the core |
Thank you @rellafella |
This is unfortunately all in one giant commit, I noticed you already had a PR open for this so if this doesn't get merged I thought at least you might find some of the aspects useful.
My main issues were around getting jest to behave with es modules, from what I could tell generally people will keep the project type as commonjs when using jest, but they will just convert files to esm as they need to.
I have converted the test suite to use vitetest instead.
As far as updates go outside of the usual require and module.exports cleanup I have made some notes below where there have been any significant improvements.