-
Notifications
You must be signed in to change notification settings - Fork 351
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
SASS 1.63.0 cannot be imported as a module #1995
Comments
Same question. Should output esm's files as In the esm environment, can use this method to load the module first:
|
Thanks for bearing with us, folks. We changed our release infrastructure pretty significantly as part of adding support for running in the browser, and this is an unintended side effect. Expect a fix some time tomorrow afternoon PST. |
It took a bit more time than expected to square the circle of browser and Node.js dependencies, but once we land google/dart_cli_pkg#131 and #2006, we should be able to release a fix for this! |
Confirmed here too.. There are 2 issues: In the generated dist file if (dartNodeIsActuallyNode) {
// This line is to:
// 1) Prevent Webpack from bundling.
// 2) In Webpack on Node.js, make sure we're using the native Node.js require, which is available via __non_webpack_require__
// https://github.com/mbullington/node_preamble.dart/issues/18#issuecomment-527305561
var url = ("undefined" !== typeof __webpack_require__ ? __non_webpack_require__ : require)("url"); I reran after adding the package.json if (dartNodeIsActuallyNode) {
// This line is to:
// 1) Prevent Webpack from bundling.
// 2) In Webpack on Node.js, make sure we're using the native Node.js require, which is available via __non_webpack_require__
// https://github.com/mbullington/node_preamble.dart/issues/18#issuecomment-527305561
var url
if (typeof __webpack_require__ !== 'undefined') {
url = Promise.resolve(__non_webpack_require__)('url')
} else {
try {
url = import('url')
} catch (err) {
url = Promise.resolve(require('url'))
}
}
url.then(url => { // rest of what's in the if (dartNodeIsActuallyNode) check wrapped in this promise Not sure why dynamic import is not used for both commonjs & ESM modules as it has been available in Node 14+ for both and dart-sass only supports Node 14+ anyway |
Dynamic import is asynchronous, and in order for Sass to remain consumable by CommonJS users it must be loadable synchronously. |
Was there a reason not to keep the default export for esm consumers? Seems bad to have an api divergence between to the two types of consumption. |
We never intended to expose a default export; that's not what's documented in our TypeScript type declarations, for example. I'm surprised to hear that that's the default way of consuming a CommonJS library that just sets That said, I think we can add a default export as well specifically to the Node.js library. I've filed #2008 to track that. |
After upgrading the version, I got this error
Then I changed the import method to import * as sass from 'sass' which fixed the problem |
We had the same problem and after the update we had to change the import since it's no longer possible to import it as default in ESM. const sass = require('sass'); Which I don't think I'm alone to simply rewrite to: import sass from 'sass'; Might be a good idea to add some examples for using the JS API with ESM here: |
Yeah is my gist moving from CJS to EJS for gulpfiles. |
@nex3 It's perhaps not just the default export that is the issue, rather the api is different for node applications depending on how the library is loaded (esm vs cjs). This is my current 1.63.3 experience CJS const sass = require('sass')
// this works (reading sass.types)
const sassNull = sass.types.Null ESM import * as sass from 'sass'
// this doesn't work (reading sass.types)
const sassNull = sass.types.Null
// TypeError: Cannot read properties of undefined (reading 'Null') So maybe coincidentally this is a default export issue, but my experience is that the api has changed for node applications depending on how the library is loaded This becomes a non-trivial divergence issue for downstream consumers that provide sass helper libraries that use dart-sass that support CJS and ESM loading. |
This appears to be fully addressed in #2010 |
SASS Version: 1.63.0
Node Version: 18.16.0
Steps to reproduce:
Package.json:
test.js:
Expected
No errors.
Log
Notes
The same import works with 1.62.0
The text was updated successfully, but these errors were encountered: