Error with default export about esbuild HOT 11 CLOSED

just bumping again to notify this still exists cause it's been 5 months now since the last one

from esbuild.

This was a separate change I made, independent of the fix for this issue: bab150d. CSS and SCSS have never been supported. I was previously importing them as text files (so the default export for each file was a string) but they are now no longer allowed to be imported, since that's almost certainly not what you want.

I was importing them as text files initially to make it easier for me to test some code bases that use CSS imports, since that at least gets them to build (although they will crash at run time). Now that people have noticed this project, I have removed this behavior so esbuild doesn't silently do the wrong thing.

I plan to eventually implement a CSS parser and integrate real CSS bundling into esbuild. But it won't be possible to import CSS files until I implement that first.

from esbuild.

@evanw I can confirm that export default still doesn't work, it doesn't parse it at all and just append it as a string.

from esbuild.

Thanks for the report.

It looks like this is because of the mismatch between how ES6 and CommonJS default exports work. This isn't surprising because I took some shortcuts with my implementation and haven't completely replicated what Babel does yet. Babel injects this code whenever you use an ES6 default import in case the imported file uses CommonJS instead of ES6:

function _interopRequireDefault(obj) {
  return obj && obj.__esModule ? obj : { default: obj };
}

This transformation also requires all code using ES6 modules to assign something to exports.__esModule which unfortunately increases bundle size. This behavior isn't standard but is sort of what the ecosystem has settled on, so I'm going to have to replicate this in esbuild.

from esbuild.

I should mention that doing this instead should serve as a workaround until this is fixed:

import * as PropTypes from 'prop-types';

from esbuild.

This should be fixed, but you didn't leave reproduction steps so I can't confirm the fix myself. Can you let me know if the issue is fixed for you or not?

from esbuild.

This changes have broken another stuff.
Now i have problem with css/scss during compiling time (v0.0.9). There was no such a problem when i used older esbuild version (v0.0.7 or v0.0.8 i dont remember exaclty)

index.jsx:3:7: error: File extension not supported: PROJECT_ROOT/node_modules/antd/dist/antd.css
import 'antd/dist/antd.css';
       ~~~~~~~~~~~~~~~~~~~~
index.jsx:4:7: error: File extension not supported: PROJECT_ROOT/src/index.scss
import './index.scss';
       ~~~~~~~~~~~~~~
App.jsx:2:7: error: File extension not supported: PROJECT_ROOT/src/App.scss
import './App.scss';

pages/sign-in/SignInPage.jsx:4:19: error: File extension not supported: PROJECT_ROOT/pages/sign-in/SignInPage.module.scss
import styles from './SignInPage.module.scss';
                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

l'll try to make repo to reproduce all of this.

from esbuild.

This is vital for web apps. When is CSS parser going to be implemented? I'm just wondering approximate date when i can be back to this project and try it again.

from esbuild.

I'm not sure, but I just filed #20 to track the CSS feature. You can subscribe to that issue to be updated when it's implemented.

from esbuild.

I can tell that "import * as multer from 'multer';" (TypeScript 4.1)
isn't working.
multer has three regular exports, and 1 default export, and esbuild actually puts the whole content
of the multer inside a function with a new "default" key, but it doesn't change the referenced bundled code to
address multer.default instead of just multer.

from esbuild.

It's not clear from your post what the code following the import statement is doing, but if you use import * as multer from 'multer' then multer is a module namespace object, not a function. This behavior is specified in the ECMAScript specification. So doing this will not work:

import * as multer from 'multer'
multer()

For historical reasons the official TypeScript compiler defaults to a loose compilation mode that deviates from the ECMAScript specification. It turns the above code into require('multer')(), which is an incorrect transformation, but doing so means the code ends up working.

Modern TypeScript code should be using the esModuleInterop TypeScript setting which makes TypeScript follow the specification. Then the code above will no longer work. Microsoft says "We highly recommend applying it both to new and existing projects" in their documentation. I do not have plans to have esbuild deviate from the specification like the TypeScript compiler does. You should write code like this instead:

import multer from 'multer'
multer()

from esbuild.