Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Provide a way to write a library that supports different dependencies on Node and the Browser

See original GitHub issue

Feature request

Author of Sass here 👋! I’m talking with @markwhitfeld about trying to get Dart Sass’s JS output running in the browser, and we’re running into some hassles with Webpack in particular that I think a new feature could address.

What is the expected behavior?

I need to meet all the following requirements:

I want to be able to distribute a single npm package with minimal duplication…
that works on both Node.js and the web…
with nothing more complicated than npm i sass and require('sass')…
and plays nicely with Webpack bundling on both platforms…
without needing any special configuration…
and uses some libraries that are only available on Node…
while gracefully degrading when those libraries aren’t available on the web.

As a special bonus non-requirement, it would be nice if the JS file we generate can be used as-is on web pages without bundling.

What is motivation or use case for adding/changing the behavior?

As far as I can tell, there’s no way to meet all of the above requirements right now. If I didn’t have to worry about Webpack, I’d just write

const chokidar = typeof window === 'undefined' ? require('chokidar') : null;

and be on my merry way, but that won’t actually prevent webpack from bundling the dependency’s code when targeting a browser so it fails requirement 4.

How should this be implemented in your opinion?

I’m agnostic on the best way to make this work, as long as it satisfies the requirements outlined above. The simplest solution might be to recognize typeof window === 'undefined’ as a magic check that can be inlined and used for constant-folding. A more explicit solution might be to provide a __webpack_target_browser__ constant that explicitly indicates whether the platform is a browser.

Are you willing to work on this yourself?

No.