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

Add vendor name to sprinkles system #831

Closed
lcharette opened this issue Dec 16, 2017 · 11 comments
Closed

Add vendor name to sprinkles system #831

lcharette opened this issue Dec 16, 2017 · 11 comments
Labels
core feature request Feature request long-range planning Long term roadmap needs discussion A decision needs to be taken by the dev team
Milestone

Comments

@lcharette
Copy link
Member

Sprinkles should use the vendor/sprinkleName convention to avoid naming conflict long term. Will avoid nasty conflicts when dealing with community sprinkles.

@lcharette lcharette added core feature request Feature request long-range planning Long term roadmap needs discussion A decision needs to be taken by the dev team labels Dec 16, 2017
@lcharette lcharette added this to the 5.0 milestone Dec 16, 2017
@mgpro94
Copy link

mgpro94 commented Apr 19, 2020

I made some changes to assets-install.js in order todo this
for my theme sprinkle (AdminLTE v4 repo here)

In my sprinkle I update all the javascript libraries and it's simply not compiles with the existing in core sprinkle.. so I made this

assets-install.zip

@Silic0nS0ldier
Copy link
Member

Difficult to be sure over such a long span of time, but I believe this ticket predates the introduction of unified npm and bower dependencies (important as duplicates can result on strange bugs, particularly if versions are mixed).

@lcharette What exactly is the intent here? Is it related to vendor packages, or protecting sprinkle assets from collision accidental?

@mgpro94
Copy link

mgpro94 commented Apr 21, 2020

@Silic0nS0ldier

In my case.. I needed to clean the package.json of the core sprinkle to be able to add bootstarp 4 (for AdminLTE Theme).

This means the a sprinkle developer can't add any npm package that conflict with the core

@Silic0nS0ldier
Copy link
Member

Yeah, that was a deliberate change and a noted risk. Bower lets you specify a "resolution" to resolve these conflicts. npm unfortunately doesn't offer an alternative. https://github.com/userfrosting/merge-package-dependencies is in need of some TLC, I'll take your scenario on board and see if I can figure out a way to satisfy your scenario without deviating from the spec. Adding support for package aliases will likely provide the outcome you are after as it'll let you install a copy of a dependency under a different name.

@Silic0nS0ldier
Copy link
Member

I've opened a ticket userfrosting/merge-package-dependencies#14

@mgpro94
Copy link

mgpro94 commented Apr 21, 2020

Package aliases can be great solution..

But.. what about package dependencies? In order to install bootstrap 4 I needed to add popper.js..
If I add a alias to popper.js, the bootstrap will still be able to install?

(I am asking because I really don't now how the npm aliases works)

@Silic0nS0ldier
Copy link
Member

An aliased package will still have its dependencies installed. As for if they too need to have conflicts resolved, I'm not sure. Its a scenario I've not had the misfortune of coming across as of yet.

@mgpro94
Copy link

mgpro94 commented Apr 21, 2020

This is the list of packages in order to install AdminLTE v3

Can you try to test them when you finish your work on marge-package-dependencies?

btw.. I can help with testing or rewriting if needed

@lcharette
Copy link
Member Author

@lcharette What exactly is the intent here? Is it related to vendor packages, or protecting sprinkle assets from collision accidental?

This ticket is for full blown Sprinkles. Currently Me/Foo and You/Foo can't coexist in our  sprinkles.json. Nothing to do with assets.

@Silic0nS0ldier
Copy link
Member

Ah, so the composer vendor name. That makes a lot more sense.

@lcharette
Copy link
Member Author

Not relevant with UF5 anymore

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core feature request Feature request long-range planning Long term roadmap needs discussion A decision needs to be taken by the dev team
Projects
None yet
Development

No branches or pull requests

3 participants