-
-
Notifications
You must be signed in to change notification settings - Fork 590
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
'import' and 'export' may only appear at the top level #304
Comments
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Thanks for opening an issue. Citing the issue template:
Please add a reproduction and we'll be happy to triage further. Please refrain from +1 replies. They'll be removed. |
Here's a reproduction with the specific package (not a direct dependency) that's causing me issues: Note that |
Thanks for adding that repro. |
There's another helpful-sounding comment here that tries to dig a little more into what's happening. |
This comment has been minimized.
This comment has been minimized.
@tiefenb Please don't add +1 comments to issues in this repo. If you have a reproduction to add, please do share it but use one of the methods mentioned above. |
Rollup Plugin Name: @rollup/plugin-commonjs i have a small Svelte demo that i keep up to date with the latest toolchains and i found that it fails to build when i updated @rollup/plugin-commonjs from "11.0.2" to "11.1.0" this weekend. works -- https://github.com/eswat2/s4e-autos The only difference between these 2 is the version of @rollup/plugin-commonjs in package.json. Running
Now, running
I hope this example helps you resolve the issue... Richard UPDATE: 2020.04.14 i refactored master to use svql instead of svelte-apollo and after i got it all working i upgraded to @rollup/plugin-commonjs 11.1.0 and it all works like a charm. The branch is still broken if i try to upgrade, but master is working fine with all the latest npm packages. Not sure if this helps or hurts your attempt to solve the problem, but it's another insight into the problem... |
seems like ponyfill.js is one of the common elements in a few of the issues reported/linked here: node_modules/symbol-observable/es/index.js
Looking at the code behind that you find this:
and that was last updated 4 years ago specifically to support rollup: benlesh/symbol-observable@7a41de9 https://github.com/benlesh/symbol-observable/blob/master/es/ponyfill.js Maybe it's time for a rewrite?... |
I ran into this issue as well, I did some debugging and I found that this file is incorrectly detected as a commonjs module: https://unpkg.com/symbol-observable@1.2.0/es/index.js?module It's possible this is because it checks for a |
I hit the same issue. For me it's React that is not detected correctly. Which is interesting because React's 'use strict';
if (process.env.NODE_ENV === 'production') {
module.exports = require('./cjs/react.production.min.js');
} else {
module.exports = require('./cjs/react.development.js');
} Unfortunately I could not dig further at the moment, but it looks like when upgrading from 11.0.2 to 11.1.0, this now gets interpreted as imports within a |
For me the error log is a bit different:
But when I do a import { isString } from './is';
import { snipLine } from './string'; Without the So it looks like the file already passed through the commonJS plugin somehow, and is passing again ? |
Notice to Future CommentersPlease do not reply with "me too" or "same here" or "+1" replies unless you are providing specifics on the code in the commonjs plugin that can be used for triage. We have enough of a sample of what isn't working at this point. If you wish to provide helpful triage information that includes references to the code in the commonjs plugin here in this repository, please do share. If you want to provide an additional reproduction, please do so by:
If you don't heed this request, your reply may be deleted. We are asking this to keep the noise down on this issue. |
Like others I encountered this error through |
This was resolved for me by downgrading |
@lukastaegert can you provide any guidance on this one? |
the fixed package resolution can be removed after rollup/plugins#304 gets fixed
Temporary fixed with commonjs({
exclude: ['node_modules/symbol-observable/es/*.js'],
}), |
Wondering if this is causing by the removal of this early exit: |
* Implemented support for dynamic requires (transferred PR) Moved from rollup/rollup-plugin-commonjs#331 * Only add dynamic loader code when dynamic feature is enabled * test(commonjs): update snapshots for easier diffing * Automatically remove user paths * test(commonjs): Prepare tests to support code-splitting * test(commonjs): Try to add a code-splitting test * Fixed code-splitting support * Cleanup: avoid importing commonjs-proxy when we only need to register * Fixed test * Updated pnpm-lock * Updated snapshots * Satisfy linter Co-authored-by: Lukas Taegert-Atkinson <lukas.taegert-atkinson@tngtech.com>
The simplest solution for now: import correct index file directly instead of letting rollup to determine module type: |
This isn't an import that I've written myself / that I can control, it's one inside of my node_modules directory. Just in case my original comment downplayed the severity, this is a fairly serious bug. Snowpack is stuck on "~11.0.0" until this is resolved. |
It seems like detection of whether to transform the module or not should be a bit more complicated. |
There's a fix pending, with the test replicating the repl supplied by @CadenP. In the future, please try to keep repros localized, without external dependencies. This helps in detection of the pain point. |
Great news! Thanks for all of your work!
Makes sense, I'll try to do that. |
What version will this be available in? |
- rollup - Downgrade @rollup/plugin-commonjs from 11.1.0 to 11.0.0 to avoid issue rollup/plugins#304 on moment - rollup - Silent cyclic rollup warnings for module moment.
How Do We Reproduce?
Expected Behavior
Bundling worked with
lodash-es
without any issues tillv. 11.0.2
.Actual Behavior
The text was updated successfully, but these errors were encountered: