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

Using grunt-svg-sprite @ 1.2.1 stop working #54

Closed
benbracha opened this issue Jun 4, 2015 · 14 comments
Closed

Using grunt-svg-sprite @ 1.2.1 stop working #54

benbracha opened this issue Jun 4, 2015 · 14 comments
Assignees

Comments

@benbracha
Copy link

In the last hour, we started to get this exception:

TypeError: Cannot call method 'distribute' of undefined
    at EventEmitter.SVGSpriterQueue.remove (/home/jenkins/workspace/ui_general_builder/node_modules/grunt-svg-sprite/node_modules/svg-sprite/lib/svg-sprite/queue.js:99:58)
    at /home/jenkins/workspace/ui_general_builder/node_modules/grunt-svg-sprite/node_modules/svg-sprite/node_modules/async/lib/async.js:49:16
    at /home/jenkins/workspace/ui_general_builder/node_modules/grunt-svg-sprite/node_modules/svg-sprite/node_modules/async/lib/async.js:646:30
    at /home/jenkins/workspace/ui_general_builder/node_modules/grunt-svg-sprite/node_modules/svg-sprite/node_modules/async/lib/async.js:1161:30
    at /home/jenkins/workspace/ui_general_builder/node_modules/grunt-svg-sprite/node_modules/svg-sprite/lib/svg-sprite.js:183:3

Seems that although we didn't change the grunt-svg-sprite version, some inner dependencies changed (specifically - the async and svgo).

Here is a comparison:

Failing:
svg-sprite@1.2.1 (cssmin@0.4.3, css-selector-parser@1.0.4, xmldom@0.1.19, mustache@2.0.0, cssom@0.3.0, xpath@0.0.9, mkdirp@0.5.1, glob@5.0.10, vinyl@0.5.0, async@1.2.0, js-yaml@3.3.1, yargs@3.10.0, winston@1.0.0, phantomjs@1.9.17, svgo@0.5.2, lodash@3.9.3)

Success:
svg-sprite@1.1.2 (cssmin@0.4.3, css-selector-parser@1.0.4, xmldom@0.1.19, async@0.9.2, mustache@2.0.0, cssom@0.3.0, xpath@0.0.9, vinyl@0.4.6, mkdirp@0.5.1, glob@5.0.10, js-yaml@3.3.1, winston@1.0.0, lodash@3.9.3, yargs@3.10.0, svgo@0.5.0, phantomjs@1.9.17)

Any help?

@benbracha
Copy link
Author

Small correction: we were working with grunt-svg-sprite "1.1.2" version, and didn't change that. Seems it was suddenly fetching a newer version of svg-sprite as well.

@jkphl jkphl self-assigned this Jun 4, 2015
@jkphl
Copy link
Collaborator

jkphl commented Jun 4, 2015

No idea why your installation seems to have auto-updated itself, but the tests for the latest version that i released 2 hours ago were running fine. Have done a full update in the meantime to pull in all the latest dependencies?

@benbracha
Copy link
Author

I did make a full update, and then it started to reproduce..

@jkphl
Copy link
Collaborator

jkphl commented Jun 4, 2015

Ah, and something more: I remember having had a similar issue in the past, where the reason finally was an SVG source file that was not a (valid) SVG file. I'm only on my mobile right now and can't search effectively, but you might find the case in the (grunt-/gulp-)svg-sprite issues.

I did a small tweak on the regular expression that tries to identify non-valid SVG files. Maybe I thus introduced a regression which makes your workflow blow up. But again, the reason would be an invalid source file ...

@benbracha
Copy link
Author

We didn't make any changes to our source files.

Another thing that may help - note that we were only depended on:

"grunt-svg-sprite": "1.1.2"

In order to overcome this issue we added:

"grunt-svg-sprite": "1.1.2",
"svg-sprite": "1.1.2"

Maybe the grunt-svg-sprite dependency of svg-sprite was changed, but this shouldn't be done without changing the version of grunt-svg-sprite itself, IMO.

@jkphl
Copy link
Collaborator

jkphl commented Jun 4, 2015

Could you please send me your complete Grunt task config and package.json dependencies (and possibly your SVG files) to joschi [at] kuphal [dot] net? I'll try to have a look at it later today or tomorrow. As I said, the build was passing fine, there must be wrong something else ...

@benbracha
Copy link
Author

Thanks, I'll send it.

@jkphl
Copy link
Collaborator

jkphl commented Jun 4, 2015

One last thing which isn't yet clear to me: Did you also try to update the grunt-svg-sprite version to the latest 1.2.1 (and run a full npm update) afterwards? Or did you (resp. your setup) try to run grunt-svg-sprite @ 1.1.2 along with svg-sprite @ 1.2.1? (The version numbers should always be in sync ...)

@benbracha
Copy link
Author

We only had grunt-svg-sprite on our package.json file, using version 1.1.2.
Our build always starts from a clean workspace.
It always got grunt-svg-sprite 1.1.2 and svg-sprite 1.1.2.

Yesterday, it started to bring svg-sprite 1.2.1 (and still grunt-svg-sprite 1.1.2).

So, as a workaround, we added to our package.json file that we should use svg-sprite 1.1.2.
It seems grunt-svg-sprite dependency of svg-sprite was changed, without changing grunt-svg-sprite version. I think..

@jkphl
Copy link
Collaborator

jkphl commented Jun 5, 2015

Ok, so you've still got grunt-svg-sprite 1.1.2 in your package.json right now, right?

Could you please update that to 1.2.2 (there has been another new release in the meantime) and run npm update afterwards? That should pull in the latest versions of both svg-sprite and grunt-svg-sprite and with some luck you're all set again.

Btw thanks for sending me your dependencies. However, without your task setup and the SVG files themselves there's nothing I could do. As I said, I suggest a problem with one of your icons (which didn't have any effect before).

@benbracha
Copy link
Author

Yes, I still got grunt-svg-sprite 1.1.2 in my package.json file.

What I don't understand - how come, from yesterday, we suddenly started to get svg-sprite 1.2.1, without doing any change to SVG files or package.json.

I think we are ok with 1.1.2, unless there is a real reason to upgrade?

As I said, now we also have svg-sprite in package.json, pointing to 1.1.2. This solved the issue.
I don't want to keep all grunt-svg-sprite dependencies and manage them manually (= match grunt-svg-sprite and svg-sprite versions all the time). I wish I could only be dependent on grunt-svg-sprite alone, and when willing to upgrade it, will do (+ testing etc.)

@jkphl
Copy link
Collaborator

jkphl commented Jun 5, 2015

What I don't understand - how come, from yesterday, we suddenly started to get svg-sprite 1.2.1, without doing any change to SVG files or package.json.

→ I don't understand this as well. As long as you don't trigger npm update or alike, nothing should change, ever.

I don't want to keep all grunt-svg-sprite dependencies and manage them manually (= match grunt-svg-sprite and svg-sprite versions all the time). I wish I could only be dependent on grunt-svg-sprite alone, and when willing to upgrade it, will do (+ testing etc.)

→ Exactly that's the real reason to upgrade. Until yesterday, grunt-svg-sprite's dependency setting was svg-sprite ^1.1.2, so even 1.2.x might have been pulled in (but not automatically, of course). With the new version(s) I changed this to ~1.2.2 so that only patches might be fetched (but no new minor versions). That's why you might want to upgrade and drop the manual svg-sprite dependency again.

However, the real problem is the error message you get when running the task. Please, let me know if it disappears after upgrading.

@benbracha
Copy link
Author

On each build we do "npm install" on a clean, fresh (no npm cache) VM environment.

Because grunt-svg-sprite was using svg-sprite ^1.1.2, it may explain that...
What I don't fully understand, is that even when we fetch each time the grunt-svg-sprite on 1.1.2, it should be a "closed" npm package and shouldn't re-fetch its dependencies. So once grunt-svg-sprite 1.1.2 was registered with npm, it should use svg-sprite 1.1.2 "for life".
Unless I'm missing something basic in npm modules behaviours, meaning: each time we fetch grunt-svg-sprite, it re-fetches its dependencies, and because it was using ^, it can explain that.
But if that is the case, how can I be sure, for any npm module, to get the right plugin each time (getting a wrong plugin may influence my build results etc.)

@jkphl
Copy link
Collaborator

jkphl commented Jun 17, 2015

But if that is the case, how can I be sure, for any npm module, to get the right plugin each time (getting a wrong plugin may influence my build results etc.)

I guess you simply cannot.

However, your original issue should be solved (or at least solvable) now, right? I'll close this one for now, but please feel free to reopen it in case of further problems.

Cheers, Joschi

@jkphl jkphl closed this as completed Jun 17, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants