canjs / can-compile

Compile CanJS Mustache and EJS views for lightning fast production apps
http://daffl.github.com/can-compile
MIT License
35 stars 15 forks source link

Remove external site dependanies #56

Closed tracer99 closed 7 years ago

tracer99 commented 7 years ago

canjs.com got broken today and the releases dir is gone. Today is the day we found out that can-compile requires external site dependancies instead of relying on node_module dependancies. Our production builds are broken until the site is fixed. Can we please not have any external script dependancies in can-compile?

lib/resolveScripts.js is the file.

mindfulmike commented 7 years ago

https://github.com/canjs/can-compile/pull/57

blai-cartera commented 7 years ago

Since the dependencies are canjs lib files and jquery that are likely available already on the local machine running can-compile, can we at least document and make the defaultPaths object configurable?

(I'm guessing this external dependency may have been implemented this way to avoid having a different version of can-compile (with a different package.json) for every version of can that it should support?)

chasenlehara commented 7 years ago

@tracer99, @mindfulmike, & @blai-cartera: I think the paths option in this section of the docs is what you’re looking for: https://github.com/canjs/can-compile#programmatically

We added this last year in https://github.com/canjs/can-compile/pull/36

tracer99 commented 7 years ago

I understand why this was setup this way back in the day when NPM had a hierchical dependancy tree. But now that it's flat, shouldn't the package simple have dependancies like any other node module and bring them in? Is there any instance where it's desirable to bring these packages in via a CDN in the first place?

chasenlehara commented 7 years ago

I think the issue is that can-compile works with a range of versions, so can-compile couldn’t include all the different versions it could possibly need to support in its package.json.

A way around that would be to ship all the versions with can-compile, but then we’re talking about including maybe tens or hundreds of MBs of library files. Maybe we could get away with only shipping the latest minor or patch version (e.g. 2.3.28 for 2.3.X), but I’m not sure if the render functions would be compatible between even patch releases.

Maybe I’m missing something though?

tracer99 commented 7 years ago

Sure, can-compile supports all the different version of CanJS.... but you have it installed in your project for your version of CanJS. Why would any one installation need support for multiple versions of CanJS.

That being said, I now understand the challenge as how does the install know which one version you care about.

chasenlehara commented 7 years ago

Yeah, that’s exactly the issue. :(

This would be a different conversation if each version of can had a corresponding version of can-compile, but I think the maintenance burden for that solution is too high.

We’re open to suggestions (and PRs 😉) for how we can improve this though. Our current solution isn’t ideal but I don’t know how we can meaningfully improve it while still making it work out of the box and not creating too much of a maintenance burden.