Browserify support #11
Comments
Browserify doesn't support dynamic dependencies. So, replace them with static ones. There are a lot, so you may need to up the maximum number of open files. Workaround for chad3814/CSSStyleDeclaration#11.
|
Forked and pushed my workaround for this issue: TreehouseJS/CSSStyleDeclaration@9fa65f9b79 |
|
ugh, yeah ugly, but if that's what's need, that's what's needed. I actually don't push versions from the master branch anymore, but from the 0.2.x or 0.3.x branches. I'll think a little bit about organizing this better. Maybe have a require for CSS2.1 and one for CSS3, and then break them down even more in there, for related properties. |
|
Ok, sounds good. Let me know what you decide and I'll integrate my changes if necessary. |
|
Would be pretty cool to somehow make this work so that we don't have to bundle the separate fork with jsdom for browserify users. One way to do it is to create a prepublish script that generates those lines ahead of time. You can then make the pretest script be |
|
my mind is slow today, I'll get this fixed and still have lazy load later today |
|
Hmm, if it can be done in an easily-maintainable way, maybe use the browser field in package.json so that browser consumers get one file and Node another? From: chad3814mailto:[email protected] actually, the problem is now it lazy loads the files because of #14https://github.com/chad3814/CSSStyleDeclaration/pull/14 I'm not sure what I can do make both happy... — |
This file will lazy-load properties but also specify the filename in the require explicitly so that it plays better with browserify. Should solve #11
|
% npm publish
npm http PUT https://registry.npmjs.org/cssstyle |
|
% npm publish
npm http PUT https://registry.npmjs.org/cssstyle |
This file will lazy-load properties but also specify the filename in the require explicitly so that it plays better with browserify. Should solve #11
For jsdom/jsdom#711, I am working on making it possible to bundle jsdom with browserify. Unfortunately, that's not possible at present for this repo, becuase browserify does not attempt to understand dynamic requires like those done to pull in the property modules.
I have fixed this by expanding the array of property names into the equivalent static call for each. This is ugly as sin, but works (if you increase the maximum number of open files on OS X).
I am going to fork this repo and apply my fix, but I think the permanent fix is to have an optional build step that does the described transformation. If I build such a thing, would you consider merging it?
The text was updated successfully, but these errors were encountered: