Cypress: Need a simple recipe for allowing import and export statements in node modules

[egucciar]

As we move towards tree shakable libraries, node modules now will more commonly be written in ES6 with export statements. For instance our organization is switching to lodash-es and we do not want to keep lodash around just for cypress. I am unable to find a very simple recipe that allows us to use import/export in node modules when importing helpers within our spec files. I would like the simplest possible recipe to achieve the above but after some searching couldn't find any.

Thanks!

[jennifer-shehane]

This repo is only for issues relating to Cypress bugs or feature requests. If you want to open an issue on usage recommendations or examples, you can open it in our docs or in our example recipes

Also, check out our community chat, it can be helpful for debugging issues or just answering questions you have about Cypress.

[egucciar]

@jennifer-shehane had I opened this as a bug "cypress node modules doesn't work with import and export" , would you have provided me with the fix in the code?

[bahmutov]

@egucciar literally the first recipe in https://github.com/cypress-io/cypress-example-recipes#readme is ES6 modules

[brian-mann]

There's already recipes around import / export here: https://github.com/cypress-io/cypress-example-recipes/blob/master/examples/fundamentals__node-modules/cypress/integration/es2015-commonjs-modules-spec.js

The recipes is found here: https://docs.cypress.io/examples/examples/recipes.html#Node-Modules

Import / export should "just work" - but what's really happening under the hood is that the preprocessor of your spec code has the responsibility of managing this.

By default we use @cypress-io/browsersify-preprocessor but you could swap that out with webpack or rollup or whatever else you want and that will take care of the packaging and serving of the JS.

[egucciar]

I can't find where in these Recipe's we modify the preprocessor to actually support import and export in node modules.

Import / export should "just work" - but what's really happening under the hood is that the preprocessor of your spec code has the responsibility of managing this.

Assuming I'm using the default preprocessor and I really want export in my node_modules to work, I am completely unsure how to actually get it to work.

Plugins is empty: https://github.com/cypress-io/cypress-example-recipes/blob/master/examples/fundamentals__node-modules/cypress/plugins/index.js

Support doesn't contain anything either.

all i can see is we are demonstrating an import statement in our spec code and the support file also has an export statement.

I check the node_module which is imported and it is using CJS (not es6) export

At this point, I'm still unable to use lodash-es (or any es6 module in node_modules), and do not know which recipe (if one exists...) addresses the usecase.

By default we use @cypress-io/browsersify-preprocessor but you could swap that out with webpack or rollup or whatever else you want and that will take care of the packaging and serving of the JS.

As for modifying the preprocessor...it sounds good in theory but in reality I'm unsure what preprocessor is used out of the box and why it does not put the node_modules through the same preprocessor as the support and specs. Ideally, I wouldn't to install a webpack preprocessor just for node modules, just configure the out of the box proprocessor to preprocess the node_modules, too.

Theoretically, i shouldnt need a completely different preprocessor to do something so simple ? the code outside of node_modules is already being processed the way I need. I'd like to extend that preprocessing to the node_modules as well.

[egucciar]

@brian-mann @bahmutov @jennifer-shehane

I appreciate your help on the matter. I created a reproducer for this:

https://github.com/egucciar/cypress-support/tree/lodash-es

and demonstrating the issue:

so please let me know why this does not work and what i need to do to get it to work?

[egucciar]

OK, since we like, really want this really badly. I wanted to dig in as far as possible, noting the error message above and searching around. Am still stuck:

I can see ok. I can modify the preprocessor..but there's no way to tell it what files to process? I am not completely understanding this which is why i think it's important to have it clarified once and for all. else all frontend projects which desire tree-shaking will need to support 2 dependencies if they want to reuse those tree-shaked libraries in cypress and in their frontend code.

[egucciar]

Ok. i havent given up yet. I parsed through the docs on browserify to try to understand what needs to be done. Simply put, I thought if i modify the entries, as per the docs, it will modify the code which will be transpiled:

But sadly this has no effect on the preprocessor whatsoever.

I also tried to do:

opts.browserifyOptions.global = true

Which ends up transpiling its own runtime...which doesnt work and is bad. :(

EDIT: The whole reason I raised this issue was to get this done quickly..I dont want to pour hours into trying different things until something works...I've gone through this mess in the pass and just ended up CJSifying my node_module durring prepublish...but now that we are using lodash-es, we have no control over that library. I suppose we can just have lodash in devDeps, but we worry the accidental use of lodash will pop up in our app by unsuspecting devs and reviewers. We do not want to import lodash into our frontend bundle and only want the tree-shakable lodash-es in our bundle, so to avoid the temptation to accidentally use lodash we want to remove it from our repo entirely.

Sadly, since we use lodash in our Cypress code, we are currently stuck with supporting both dependencies until I can get some assistance on how this is to be done the right way

[bahmutov]

Right now the recommended way for all libraries it to ship es5 and optional es6 modules. Exporting and importing es6 modules already works for your local code (not the node_modules). I think we could make a note in this example about it and then maybe advise how to transpile node_modules too using https://github.com/cypress-io/cypress-browserify-preprocessor

[bahmutov]

I have opened https://github.com/cypress-io/cypress-browserify-preprocessor/issues/19 and we then can update and add note to recipes README

[egucciar]

@bahmutov I do not know why lodash (hugely popular library) recommends to use lodash-es for tree-shakeable es6 module & why thing dont "just work" out of the box (i.e. when using webpack, it uses es6 version and when using node, it uses cjs version) but this is the path lodash advises developers to go down if we want to leverage tree-shaking abilities.

Infact, as tree-shaking is used more, people will begin to move towards an esm-by-default model because tree-shaking is only possible with esm and static import/export analysis. It would surely be pertinent for all bundle processing systems to be able to handle export and import "natively" (as webpack does today) in order to take full advantage of tree shaking.

Thank you SO much for opening that example against browserify. I'm still unsure if its even possible given my current failed attempts, but I will be so excited to see it through! thank you!

[bahmutov]

See cypress-browserify-preprocessor 19 for solution

[egucciar]

@bahmutov my coworker and i just celebrated this! thank you! I was failing miserably :)

[bahmutov]

🎉

Sent from my iPhone

On Oct 30, 2018, at 21:53, Erica Gucciardo [e-mail] wrote:

@bahmutov my coworker and i just celebrated this! thank you! I was failing miserably :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.