Open dimylik opened 8 years ago
I has been absent for a long time from keyboard. I will now look into it.
That's weired, as far as I remember, aliasify is a browserify extension. Not sure if it really should go into the main dependencies.
Could you provide your package.json
?
Hi,
my package.json is pretty long and I can't post it by security reason, but we are using "browserify": "^13.0.0" in the project.
If you try to build simple Angular project using pdfmake-browserified dependency in it, you will get same error about aliasify
thanks
That's strange. I use it in one of my Angular projects and do not get the described error.
I have the same problem here. Shouldn't aliasify be a dependency instead of a devDependency in pdfmake-browserified? Why is this issue closed?
aliasify
is used during Browserify-compilation. The resulting javascript does not depend on aliasify
.
Can you please provide your package.json as well as the code you use to require and include this module?
Last but not least, I need node and npm version.
I will then be able to look into and reproduce the problem :-)
Running into this issue as well.
Node v5.10.0 Npm 3.8.3
@patrickberkeley Which Angular version are you using? Could you post the relevant parts of your package.json and the snippet you use to include/require the module?
@xErik I'm using Ember.js with ember-browserify.
I included pdfmake-browserified
as follows:
import createPdf from 'npm:pdfmake-browserified';
Here's the package.json:
{
"name": "some-name",
"version": "0.0.0",
"description": "Small description goes here",
"private": true,
"directories": {
"doc": "doc",
"test": "tests"
},
"scripts": {
"build": "ember build",
"start": "ember server",
"test": "ember test"
},
"repository": "",
"engines": {
"node": ">= 0.10.0"
},
"author": "",
"license": "MIT",
"devDependencies": {
"broccoli-asset-rev": "^2.4.2",
"c3": "^0.4.11",
"d3": "^3.5.0",
"ember-ajax": "^2.0.1",
"ember-browserify": "1.1.12",
"ember-cli": "2.6.2",
"ember-cli-app-version": "^1.0.0",
"ember-cli-babel": "^5.1.6",
"ember-cli-custom-assertions": "0.0.6",
"ember-cli-dependency-checker": "^1.2.0",
"ember-cli-deploy": "1.0.0-beta.1",
"ember-cli-deploy-build": "0.1.1",
"ember-cli-deploy-display-revisions": "0.2.2",
"ember-cli-deploy-gcloud-storage": "0.1.1",
"ember-cli-deploy-gcs-index": "0.0.2",
"ember-cli-deploy-revision-data": "0.3.0",
"ember-cli-htmlbars": "^1.0.3",
"ember-cli-htmlbars-inline-precompile": "^0.3.1",
"ember-cli-inject-live-reload": "^1.4.0",
"ember-cli-jshint": "^1.0.0",
"ember-cli-mirage": "0.2.1",
"ember-cli-moment-shim": "2.2.0",
"ember-cli-qunit": "^1.4.0",
"ember-cli-release": "^0.2.9",
"ember-cli-sass": "5.5.1",
"ember-cli-sri": "^2.1.0",
"ember-cli-uglify": "^1.2.0",
"ember-composable-helpers": "1.1.2",
"ember-concurrency": "0.7.15",
"ember-data": "^2.6.0",
"ember-drag-drop": "0.4.0",
"ember-export-application-global": "^1.0.5",
"ember-inline-svg": "0.1.7",
"ember-load-initializers": "^0.5.1",
"ember-moment": "6.1.0",
"ember-paper": "git://github.com/IcarusWorks/ember-paper.git#jm-paper-input",
"ember-pikaday": "git://github.com/IcarusWorks/ember-pikaday.git#fix-min-max-date",
"ember-resolver": "^2.0.3",
"ember-simple-auth": "1.1.0",
"ember-transition-helper": "0.0.6",
"ember-truth-helpers": "1.2.0",
"loader.js": "^4.0.1"
}
}
@patrickberkeley Thanks. I take it, that you excluded pdfmake-browserified from the current package.json, due to the error. Could you please paste the complete error?
I do not know ember, but I suspect that ember-browserify tries to pre-process pdfmake-browserified, without the necessity of pre-processing it.
./build/pdfmake-browserified.min.js
should be ready to go, as aliasify is just a pre-processor for browserify. Aliasify is not part of the resulting build.
@xErik correct on why pdfmake-browserified
is not in the package.json I posted.
Here is the error:
The Broccoli Plugin: [object Object] failed with:
Error: Cannot find module 'aliasify' from '/Users/patrickberkeley/Code/pdfmake-sample/node_modules/pdfmake-browserified'
at /Users/patrickberkeley/Code/pdfmake-sample/node_modules/resolve/lib/async.js:46:17
at process (/Users/patrickberkeley/Code/pdfmake-sample/node_modules/resolve/lib/async.js:173:43)
at ondir (/Users/patrickberkeley/Code/pdfmake-sample/node_modules/resolve/lib/async.js:188:17)
at load (/Users/patrickberkeley/Code/pdfmake-sample/node_modules/resolve/lib/async.js:69:43)
at onex (/Users/patrickberkeley/Code/pdfmake-sample/node_modules/resolve/lib/async.js:92:31)
at /Users/patrickberkeley/Code/pdfmake-sample/node_modules/resolve/lib/async.js:22:47
at FSReqWrap.oncomplete (fs.js:82:15)
The broccoli plugin was instantiated at:
undefined
@patrickberkeley It looks like broccoli is reading the package.json file and attempting to browserify the module, as that's what the package.json says to do. It's a little more complicate than what I've described based on what I've seen in all the modules at play here (Meaning, the file configures browserify to use aliasify, which is then missing as it's not needed since the file is already built). However, I suspect you can fix this by excluding the pdfmake-browserified module from the broccoli processing queue via this SO answer:
http://stackoverflow.com/questions/30686368/exclude-folders-from-builds-in-brocfile
The other quick and dirty solution to this would be to fork this repo, change the package.json or add everything except the build*.js to .npmignore then npm install github:yourname\pdfmake-browserified which will use your forked version of the module.
It's already unfortunate that this build doesn't take the latest pdfmake before browserifying it.
The third and probably best solution here is to use the original PDFMake module and then Browserify THAT module yourself as part of your pipeline. If you're packing everything into a single file anyways, then you should use the non-browserified version imho. I could be wrong on this so feel free to correct me.
We tried using browserify-shim
in order to avoid the re-compile but for some reason it was still doing something else (the build time was still high)
We ended up loading this particular script async since our use case is very straightforward.
But indications in the readme on how to avoid to re-compile the module would be nice.
As soon as I moved "aliasify": "^1.7.2" from devDependencies to dependencies in your package.json, all works fine!
should you do that in next release?
workaround is adding latest "aliasify" to project main dependencies