We can:
npm install --save modernizr
It seems that we still need to:
./bin/modernizr
Before we can:
require('modernizr');
This seems odd within the npm ecosystem. Is there a better way?
in what way do you need to ./bin/modernizr before you require it?
Do you not need to build modernizr within the the node_modules/modernizr directory that you get when you npm install modernizr in order to then have a modernizr.js that can be required via node/CommonJS/Browserify?
Yes. The module is for the builder, not for the feature detects themselves.
On Sat, Aug 1, 2015, 3:39 PM Jerome Covington [email protected]
wrote:
Do you not need to build modernizr within the its node_modules directory
in order to then have a modernizr.js that can be required via
node/CommonJS/Browserify?—
Reply to this email directly or view it on GitHub
https://github.com/Modernizr/Modernizr/issues/1623#issuecomment-126948264
.
Closing as AS DESIGNED
From my perspective, the node_modules dir of my app can/should be able to be a black box that does not need any more tinkering to allow my app to "just work" when somebody runs npm install within my project root, with "modernizer" listed in my package.json as a dependency. Ah well.
You are confusing the purpose of he module. It does just work - for its
intended purpose. A code generator. If you want to use modernizr as a
dependency for your front end code, then you should generate that
standalone file and check it in directly, rather than using an npm module.
On Sat, Aug 1, 2015, 4:33 PM Jerome Covington [email protected]
wrote:
From my perspective, the node_modules dir of my app can/should be able to
be a black box that does not need any more tinkering to allow my app to
"just work" when somebody runs npm install within my project root, with
"modernizer" listed in my package.json as a dependency. Ah well.—
Reply to this email directly or view it on GitHub
https://github.com/Modernizr/Modernizr/issues/1623#issuecomment-126951864
.
Ok, thanks for clarifying. Personally I am working towards a future where all the dependencies of my project, both serverside and front end, can be managed within the "dependencies" object of my package.json. Understood that is not the intended purpose of this module.
Good luck!
On Sat, Aug 1, 2015, 5:49 PM Jerome Covington [email protected]
wrote:
Ok, thanks for clarifying. Personally I am working towards a future where
all the dependencies of my project, both serverside and front end, can be
managed within my package.json. Understood that is not the intended
purposes of this module.—
Reply to this email directly or view it on GitHub
https://github.com/Modernizr/Modernizr/issues/1623#issuecomment-126955860
.
I understand now that this is "AS DESIGNED" but I think that doesn't necessarily mean that this design is a good idea. People manage their projects with npm, automate their builds and environments with docker and other useful tools. If this project doesn't follow the logic of these modern tools then it's likely that it is simply not worth using Modernizr for modern projects.
I'm not deeply understanding the core ideas behind Modernizr, I just know that I'd expect an npm package that could be a non-global dependency of my projects, and that could be used something like:
import {passiveeventlisteners} from 'Modernizr'
If it's not like this then it seems to be easier if I write the feature checking myself than changing my development and production scripts to have Modernizr customized and built.
PRs are welcomed
Agree with the statements from @g-borgulya and @jeromecovington. I’m new to Modernizr and was expecting it to work as import { feature } from Modernizr. I’m too lazy to using it in a different way.
@g-borgulya @jeromecovington @djibarian I’ve made this possible in my fork of Modernizr: https://github.com/niksy/modernizr-esm
Most helpful comment
From my perspective, the
node_modulesdir of my app can/should be able to be a black box that does not need any more tinkering to allow my app to "just work" when somebody runsnpm installwithin my project root, with "modernizer" listed in mypackage.jsonas a dependency. Ah well.