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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Cannot use import statement outside a module" while using karma-esbuild #38

Open
karl-thomas opened this issue Aug 9, 2021 · 5 comments

Comments

@karl-thomas
Copy link

karl-thomas commented Aug 9, 2021

Hello there, I'm working on switching my team off of gulp/browserify/babelify and I've gotten some problems worked out of the karma config, but I'm having an issue now where its sending un-esbuild-processed syntax to the browser, or something. It fails on the first test it runs because we are using ESM style import syntax in our file, and I'm unsure why we are getting this in the first place. I know that node and (some) browsers don't support these features, but this was not an issue before, and I thought that esbuild would transpile those away into something else, as it's doing in our main prod build. Any help would be appreciated. here's my karma config.

{
    basePath: "",

    frameworks: ["jasmine-jquery", "jasmine", "es5-shim"],

    files: [
      {
        pattern: "spec/javascripts/**/*_test.+(js|jsx)",
        watched: false,
        included: true,
        served: true,
      },
    ],

    exclude: [],

    preprocessors: {
      "spec/javascripts/**/*_test.+(js|jsx)": ["esbuild"],
      "app/assets/react/**/*.(js|jsx)": ["esbuild"],
    },

    esbuild: {
      nodePaths: [
        '/Users/NDA/work/NDA/app/assets/react/',
        '/Users/NDA/work/NDA/spec/javascripts/',
        '/Users/NDA/work/NDA/vendor/assets/javascripts/'
      ],
 
     define: {
        'process.env.NODE_ENV': PROD_MODE ? '"production"' : '"development"',
        global: 'window',
      },
      resolveExtensions: ['.jsx', '.js', '.json'],
      loader: {
        '.js': 'jsx',
      },
      external: [
        "react/addons",
        "react/lib/ReactContext",
        "react/lib/ExecutionEnvironment",
      ],
      target: "es2016",
      format: "iife",
    },

    coverageReporter: {
      reporters: [{ type: "html" }],
    },

    reporters: ["progress", "coverage"],
    port: 9876,
    colors: true,
    logLevel: config.LOG_INFO,
    autoWatch: false,
    browsers: ["ChromeHeadless"],
    singleRun: true,
  }
@marvinhagemeister
Copy link
Owner

marvinhagemeister commented Aug 9, 2021

Thanks for filing an issue. It's a bit hard to inspect this further without any code and only seeing the karma config file, so here are some wild guesses you could look into:

The module error usually occurs when a script was loaded without the type attribute:

<script src="foo.module.js"></script> <!-- this fails -->
<script src="foo.module.js" type="module"></script> <!-- this is correct for loadding ESM -->

By default karma inserts script tags without the type="module" attribute. You can tell karma to add that attribute by specifying it next to the test patterns.

files: [
  {
    pattern: "spec/javascripts/**/*_test.+(js|jsx)",
    watched: false,
    included: true,
    served: true,
    
    // This bit here
    type: "module",
  },
],

Another cause could be a dependency that's not correctly transpiled to non-ESM. The stack trace of the error you're seeing should give hints to that.

Another thing you could try is removing the format: 'iife' option. karma-esbuild should work by default.

That's all I can think of for now.

@karl-thomas
Copy link
Author

No luck on that but Thank you! I was trying to find where I could apply that attribute via karma. I think our karma version is just way too out of date for that option, I'm going to try to upgrade it. I am a bit confused on why we would need that type attribute though, because our front end code works with out it, I thought esbuild more or less removes all the imports/exports when bundling.

What code would you like to see? I can try making a repro-repo

@jridgewell
Copy link
Collaborator

If I had to guess, it's the external option. That'll cause esbuild to leave an import/require statement in the output bundle to get the package.

@karl-thomas
Copy link
Author

karl-thomas commented Aug 10, 2021

Okay so it does work now, with the type: module on the file thing after upgrading karma to a version that supports that (i just went up to the newest one). I also had to upgrade a few other things, namely karma-coverage and lodash. Some tests fail now, but i expected that. what's weird is now our tests run all the way through, with some failures due to the upgrade, and then they automatically run again. im not sure whats causing that. i assume that one of the plugins or frameworks are making some file thats picked up by the filewatcher or something. i don't know if it pertains to this plugin. I'm trying to process-of-elimination what could be causing it to do that now

edit: never mind. adding and removing the type: module from the file settings doesn't appear to be doing anything, it is still ultimately failing, but a bit more obtuse now. it's running through some of the tests an eventually will print out this

Chrome Headless 92.0.4515.131 (Mac OS 10.15.7) ERROR
  An error was thrown in afterAll
  Unhandled promise rejection: undefined thrown

not sure what that is about, but when I open up the browser and go to the debug html it has a bunch of Cannot use import statement outside a module, one for each fo the test files I think. not sure what to do about any of this. it may be due to the external option, but it's failing on the very first import each time.

it gets through about half the tests then fails

@karl-thomas
Copy link
Author

karl-thomas commented Aug 11, 2021

Oh its adding numbers to the end of Exports. so import {Nav} from 'react-bootstrap' gets imported as Nav2, which messes up the tests that are finding components by an exact-matching name. I'd like to not be happening, is there some config thing I'm messing up?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants