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

Remove build step / bundling / babelifying #652

Closed
Qix- opened this issue Dec 19, 2018 · 0 comments
Closed

Remove build step / bundling / babelifying #652

Qix- opened this issue Dec 19, 2018 · 0 comments
Labels
change-major This proposes or provides a change that requires a major release
Milestone

Comments

@Qix-
Copy link
Member

Qix- commented Dec 19, 2018

In 4.x, the build process was deprecated. In 5.x, I'd like to see it removed.

I know this is going to cause problems for some users (that are mis-using debug or mis-using version ranges), but I'm hoping the legacy users that still rely on debug@* (seriously, stahp doing that...) were fixed up a bit after the release of 4.x since it introduced enough breaking changes to get that ball rolling.

Ultimately, debug is not a complicated package. It's not a package that warrants the use of splat-property-functional-ternary-resolvers or whatever new crazy ecmascript proposal came out last week.

We should be supporting the language features supported by the latest LTS Node (at the time of this writing, it's currently 8.x and will soon be 10.x with the new year) and nothing newer.

Browser Users

You get an extra big header because I know the majority of angry people will be browser users 🙃

I see you. However, with the current state of Javascript and frontend development, Babelification has become a part of life.

If you want to see the current position regarding ES5 bundling and whatnot, please see Sindre Sorhus's wonderful writeup at this link: sindresorhus/ama#446 (comment)

The only subtle difference is that debug was originally intended to be both Node.js and first-class browser compatible. I intend to keep it that way, with a few changes with where each of these implementations live (see #556).

I ultimately want to get rid of this weird, uncertain split of functionality entirely as it causes endless build problems and questions and assumptions and issues and etc.

While this ticket is relatively small and actionable, please see #556 and #644 for more context as to what changes to expect in 5.x. It's still not entirely certain the landscape of user experience, however...

... that's why several of the open issues are still RFCs and I urge everyone to contribute to them as I would love to hear feedback.

@Qix- Qix- added the change-major This proposes or provides a change that requires a major release label Dec 19, 2018
@Qix- Qix- added this to the 5.x milestone Dec 19, 2018
Qix- added a commit that referenced this issue Dec 19, 2018
Qix- added a commit that referenced this issue Dec 19, 2018
Qix- added a commit that referenced this issue Dec 19, 2018
Qix- added a commit that referenced this issue Dec 19, 2018
@Qix- Qix- mentioned this issue Dec 19, 2018
11 tasks
@Qix- Qix- closed this as completed in #655 Dec 19, 2018
Qix- added a commit that referenced this issue Dec 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
change-major This proposes or provides a change that requires a major release
Development

No branches or pull requests

1 participant