Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for the "module" package.json field #5485

Closed
wants to merge 8 commits into from
Closed

Add support for the "module" package.json field #5485

wants to merge 8 commits into from

Conversation

PepijnSenders
Copy link
Contributor

Closes #2702

This is a duplicate of #2704.

Original description:

This is used in modern es module codebases to designate the entry point for code that makes use of import/export instead of commonjs. Jest doesn't need to care about whether or not that destination code is actually an ES module, just that the path gets resolved 馃檭

@PepijnSenders PepijnSenders mentioned this pull request Feb 7, 2018
@SimenB
Copy link
Member

SimenB commented Feb 7, 2018

A single failing test, mind fixing it?

Also failing flow

@PepijnSenders
Copy link
Contributor Author

Yes, I will work on this in a bit!

@PepijnSenders
Copy link
Contributor Author

PepijnSenders commented Feb 7, 2018

So I got it to work for local modules, now trying to get it to work for imported modules.

I've got it to work for modules that are imported like this already:

import { connect } from 'react-redux';

But if you do something like this it won't work:

import isPlainObject from 'lodash-es/isPlainObject';

This doesn't work yet, because I haven't come up with a way yet to track the modules that are resolved as files. Will revise this PR tomorrow, please let me know if you have any ideas!

const resolveTarget = path.resolve(name, pkgentry);

if (isRequiredByModuleField) {
REQUIRED_BY_MODULE_FIELD_CACHE[name] = true;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sadly I reverted to keeping a local CACHE singleton here, if you have any ideas, please let me know as well!


try {
if (willTransform) {
const transformedSource = this.transformSource(
filename,
content,
instrument,
options.isRequiredByModuleField,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For some reason, shouldTransform is called twice, I just passed it through for now. Maybe someone from the jest team can check if it is actually necessary to call it twice.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Twice within the same file or same code path?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same code path.

@PepijnSenders
Copy link
Contributor Author

@SimenB any chance you have time checking this out with me?

@SimenB
Copy link
Member

SimenB commented Feb 19, 2018

Could you rebase and fix the flow errors?

Anything in particular you want answered?

@PepijnSenders
Copy link
Contributor Author

So mostly the problem is what I commented here: #5485 (comment). The story about deep imports.

@CosminIonascu
Copy link

Hi, any updates on this?

@dan-kez
Copy link

dan-kez commented Mar 24, 2018

I would love to see this merged. If there's a way I can help let me know!

@PepijnSenders
Copy link
Contributor Author

@dmk255 @CosminIonascu this PR works until the point where packages require other packages through the .module field. Like react-redux requiring lodash-es, I鈥檒l be on holidays for a week now, pleass feel free to tinker with this PR!

@rickhanlonii
Copy link
Member

@PepijnSenders any chance you could wrap this up?

@PepijnSenders
Copy link
Contributor Author

@rickhanlonii I'm pretty busy in general, but I got stuck on the thing I mentioned above. Not sure how other system manage this, but it's pretty hard to differentiate which modules you can load with the module field and which you can not load.

@MQuy
Copy link

MQuy commented Sep 12, 2018

are there any updates in this pr? I think it is super helpful if we can merge this one :D

@SimenB
Copy link
Member

SimenB commented Sep 17, 2018

Does the browser flag support deep modules? If not, we can land this without it, and create an issue for a future improvement.

Or, we can just land this without the deep support, that's better than nothing, isn't it?

@rickhanlonii
Copy link
Member

Bump

@github-actions
Copy link

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 12, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support the "module" package.json field
8 participants