Debug: 4.1.1 version of debug crashes IE11 with syntax error. downgrading to 3.2.6 fixes issue

[onexdata]

Can I still use debug 4x with non ES6 browsers? Is there some way to use a transpiled version or if I want to support IE11 stick with 3x?

[Qix-]

You use Babel.

[onexdata]

I do use babel...

I'm using @babel/preset-env, which doesn't seem to transpile node_modules, or doesn't without setting up additional config. Can you possibly point me in the right direction? This has been taking up a lot of my time.

[Qix-]

You should use a packer like Rollup or Webpack. A quick google search should tell you more than you need - this is a widely documented topic.

[onexdata]

I use webpack.... I use it with @babel/preset-env... which most people recommend and the community is moving towards.

I think (?) the trouble is that it doesn't transpile node_modules. I have nearly 30 dependancies but debug is the only one causing the issue. I understand and respect the choice to remove es5 support for debug. I am asking for just a pointer towards how to get babel to do this for debug. I see this project has tons of people asking exactly what I am asking, but they are told to also just google it. I have done so sir, all day. I can't find an answer.

my babel config is this...

{
  "presets": [
    [
      "@babel/preset-env",
      {
        "useBuiltIns": "usage"
      }
    ]
  ],
  "include": [
    "./src/*",
    "./node_modules/debug/*"
  ],
  "plugins" : [
    "@babel/plugin-syntax-dynamic-import"
  ]
}

When I change something in the /node_modules/debug folder, I see webpack triggers a recompile, which leads me to believe babel is being told to include the right folder to transpile, but however it's not actually transpiling it. I know this because in IE11 I see the new code I put into debug, and I also still see the ES6 code debug is using, not transpiled. I have been looking all over the community for an answer to this and I haven't been able to find one.

If you pointed me in the right direction, you could also be able to point every new issue that gets opened for this project because of this same issue, right to your link you provide me... it would also help people googling for an answer... because when I google for an answer to this, I get results that point to other people opening issues right in this repo.

[onexdata]

For anyone else that is googling how to get the latest version of debug to transpile to ES6, or if someone tells you to google it, and google sends you back to the debug repo like it did me, here is how you get out of your own personal hell...

Add this exclude to babel-loader (note this makes an exception for @feathersjs and debug, which means babel will transpile those two node modules for you as well, just replace "@feathersjs" with any other module you want to also transpile for ES6, and add a "|" to deliminate them).

{
  test: /\.js?$/,
  exclude: /node_modules(\/|\\)(?!(@feathersjs|debug))/,
  loader: 'babel-loader'
}

If you're using Quasar-framework, just put this in quasar.conf.js and wrap it around extendWebpack like this:

extendWebpack (cfg) {
  cfg.module.rules.push({
    test: /\.js$/,
    exclude: /node_modules(\/|\\)(?!(@feathersjs|debug|@lifeio))/,
    loader: 'babel-loader'
  })
  // Your other additions here.
}

If you're using create-react-app, you have to eject. If you don't want to or don't know what that means, you have to use debug 3.2.6 or lower, which supports ES5.

@Qix- For what it's worth, this should be in the debug documentation as you can tell from the people creating issues, this is a big human time waster. For every dev that creates an issue, 10 do not. This stops developers using the latest version of debug dead in their tracks and most devs don't know why; most packages support ES5 so most developers see this issue first with debug. When you finally track it back to debug, debug has no documentation about it, and for some reason you tell them to just figure it out.

Other maintainers put the decision to abandon ES5 in their docs, and give them details for how to fix it (this is finally how I found out how to fix it, and got some help from the awesome devs at feathers)...

https://docs.feathersjs.com/api/client.html#module-loaders

Why not do it for debug? Wasn't there a time when you didn't know everything? When you move to another language won't you be happy to find devs point you towards a fix or show you how to fix it? Do you realize for every person you tell to just google it, an angel dies, and you cost that dev and every dev that finds your response to them many hours of work? Don't you want to make the world better?

Don't let your disdain for IE11 turn into disdain for your fellow humans that unfortunately still have to support it. They didn't do anything wrong, and they even look up to you man, you maintain stuff and hold up the infrastructure... rainbows and unicorns man, rainbows and unicorns :)

[naftis]

I use create-react-app and had problems with debugs latest version 4.1.1. Solved with downgrading as suggested, but I cannot configure Babel without ejecting, so I feel like this is still an open issue.

[arecvlohe]

Seems fair to put something like what @onexdata posted above into the README. Unfortunately (or maybe fortunately?) we all aren't as experienced on the nuances of this issue. If just googling is the answer then I encourage more people to comment on this issue using some keywords (debug, webpack, process.env.DEBUG, DefinePlugin) so google can index it and we can all find it better.

[Qix-]

For what it's worth, this should be in the debug documentation as you can tell from the people creating issues, this is a big human time waster.

ES6 is ES6. This is the standard right now. Most packages nowadays use it (e.g. most of @sindresorhus's packages, which garner over 12% of all npm downloads (probably much higher now). Further, most packages that use it do not transpile as a release step.

create-react-app should be handling this better - if you're seeing problems with how create-react-app bundles its dependencies, you should open a ticket with them. It's not my job to educate the masses on how to use transpilers or bundlers.

As for keywords requested by @arecvlohe, I get some interesting results with how to bundle web application babel transpile all dependencies.

Why not do it for debug? Wasn't there a time when you didn't know everything? When you move to another language won't you be happy to find devs point you towards a fix or show you how to fix it?

• It's not another language.
• ES6 is used in a lot of places, but debug is unfortunately the first place people seem to discover ES6 exists.
• Babel is not new. Stop acting like it is.
• There are heaps of guides, discussions, issues, and other reasonable discourse on how the current ecosystem works.

I apologize for any perceived annoyance on my part - it's simply because I'm annoyed. This repository was previously in shambles for over a year - some people literally thought it was a general debugging repository for anything related to Node.js or npm, simply because it's one of the top downloaded npm packages.

Unfortunately, it's also the place where people seem to go to ask questions about ES6 or bundling (e.g. this ticket).

Do you realize for every person you tell to just google it, an angel dies, and you cost that dev and every dev that finds your response to them many hours of work?

This is dramatic. I'm not a frontend developer nor is it my passion but everything I've ever needed to solve a frontend tooling problem was found with some simple google searches. That's a skill every developer should have, regardless of focus.

My very much proper, un-special use of ES6 is definitely not a common cause for wasted effort. I see people using it to great effect quite frequently. If you're having problems understanding how your builds or bundling work, perhaps you should spend some more time learning about that - not placing the blame on me. Just a suggestion.

Don't let your disdain for IE11 turn into disdain for your fellow humans that unfortunately still have to support it.

I don't have disdain for IE11. I simply do not like writing ES5 anymore as it's a burden to maintain and leads to more bugs and messier code. Plus, ES6 is proper and modern and well supported, documented, etc., even if you _yourself_ are struggling with the tooling (which is not ES6's nor my own fault - it's no secret the web development ecosystem is a blithering bloated mess at the moment).

---

If you want my _personal_ advice, which does not necessarily reflect the official stance of any of the maintainers here, nor will it necessarily reflect what is commonly considered "proper":

Don't use webpack, use rollup. It's the only bundler that hasn't given me a headache, especially since I don't work with frontend a whole lot.

Also, I've never felt the need to use create-react-app. I don't personally find it that difficult to mount React onto a harness HTML page and have never seen a need for anything more complicated than that. It's also worth learning, IMO.

I've also never used babel-loader - I'm not even sure what it does as the only place I've ever seen it mentioned is here in the issues. @babel/preset-env has been sufficient enough for me, _maybe_ with some extra stuff thrown in to get async/await working how I'd like.

Further, while rollup is decent enough with basic things, I've found myself using gulp a bit, as much as I'm a build systems nerd and dislike how gulp is designed.

The way I've been structuring my hierarchy:

• Gulp uses babel via gulpfile.babel.js and .babelrc, the latter of which is _only_ used to get gulp working (_not_ for the entire project). Therefore, I only target node 6 in .babelrc.
• Gulp uses rollup-stream to invoke Rollup, which then uses rollup-plugin-babel and rollup-plugin-node-resolve for the transpilation - all of which is managed directly in the gulpfile.babel.js. Here is the guide I followed. Take my word on the other Gulp+Rollup plugins: they're broken, some of them conceptually and fundamentally so, and wasted loads of my time.
• The rollup babel plugin uses the configuration passed directly to the function, making sure _all_ of my project's configuration is in the same spot. As I mentioned earlier, don't rely on the .babelrc - be explicit. It's also nice since _all_ of the build configuration resides solely in your gulpfile (except maybe tsconfig for typescript projects, since IDE's/tooling needs that file to exist).

This has been sufficient for me for a few projects now, but I'm sure it's not as refined as it could be.

Again, this is how I _personally_ set up my build pipelines for frontend assets, YMMV.

And no, sorry, none of this advice is going in the readme.

[Diokuz]

@onexdata and everyone else, who don't want to create workarounds for webpack config: you could use my es5 compatible fork https://www.npmjs.com/package/@diokuz/debug

yarn add @diokuz/debug

It is basically the same, just transpilled to es5 :)

Or you could use 3rd version of debug:

yarn add debug@^3

[Qix-]

I don't recommend using forks of modules simply because they prevent you from receiving potential security updates if they occur. Also, I cannot vouch for the safety of the code and thus cannot provide support if you use them.

[mark-ukr]

So compile your library to ES5-compatible code with Babel, and you will never get feedbacks like this.

The problem is that Babel never compiles anything in node_modules out-of-the-box, because it assumes that all code in node_modules is already compiled. In order to enable compilation people have to change the Babel config.

If they add the entire node_modules, it will seriously degrade build performance.
If they add exclusion for every module like debug, which does not have ES5-compatible code in the distibution, it will break the DRY principle (they will have to remember to add debug to exclusions for each project that uses debug).

Please, just add a compilation step or let us do it for you in a PR.

[Qix-]

So compile your library to ES5-compatible code with Babel, and you will never get feedbacks like this.

Bring your project into the year 2019 and you will never be blocked by stubborn maintainers.

The problem is that Babel never compiles anything in node_modules out-of-the-box, because it assumes that all code in node_modules is already compiled.

Only that first statement is true. The latter isnt really fair as Babel doesn't make assumptions about anything.

If they add the entire node_modules, it will seriously degrade build performance.

Eh, not really. I'm tired of hearing this argument. You don't compile the entirety of your node_modules. You allow ES6 import/export semantics to selectively import things.

they will have to remember to add debug to exclusions for each project that uses debug

And like half of the modules written in the last 5 years.

Please, just add a compilation step or let us do it for you in a PR.

No, sorry. Locking.