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

Packages need a principled way to access their files (and their build contents) #2506

Closed
mizzao opened this Issue Sep 3, 2014 · 8 comments

Comments

Projects
None yet
7 participants
@mizzao
Copy link
Contributor

mizzao commented Sep 3, 2014

I know this isn't an explicit bug, but there is a strong need to give packages a better way to access files before and during the build process. Many packages, including several of mine, have broken across the 0.9 migration with no clean way to fix them. I'll give some examples here; please consider how we might support these use cases.

The mizzao:sharejs package integrates the ShareJS concurrent editor stack into a Meteor app. To do this cleanly, it includes client-side Javascript editors such as the Ace editor (and in the future, CodeMirror). These editors are gargantuan libraries with many little snippets of Javascript and CSS that can be loaded as themes or addons. It's not feasible to keep track of all these files as hardcoded paths in package.js, so pre 0.9 they were processed in the following way and added as assets:

https://github.com/mizzao/meteor-sharejs/blob/master/package.js

Note that we need to manually find the folder for the package (previously packages/meteor-sharejs) and search through it for the relevant files. In 0.9, this no longer works without some hacky hoops: the path is packages/mizzao:sharejs when being used as part of an app, and just ./ when the package is being tested. That means any package that does this will need to keep track of these different cases. It would be a lot easier to be able to grab the current working directory (that add_files uses as a base) or references to files in the package's current directory.

@acreeger implemented the full version of this to make moment compatible for 0.9, 0.8.3, and in testing, and as you can see, it's pretty ugly:

https://github.com/acreeger/meteor-moment/blob/adding-locales/package.js

On a similar note, the Meteor 0.9 build process should be better documented - how raw files are treated, how the built files are stored, and what gets sent to the package server - and how build plugins interact with this process. build-fetcher broke in the transition from 0.8.3 to 0.9, and packages using it (such as mizzao:jqueryui and mizzao:openlayers are unpublishable with ENOENT errors for files that shouldn't actually exist on the filesystem. I'll open another issue with the specifics, but I think generally packages that do more advanced things than just wrapping something upstream need better ways to deal with files than with ad hoc fs code.

Related: #2488.

@mizzao

This comment has been minimized.

Copy link
Contributor Author

mizzao commented Sep 4, 2014

Some discussion about this would be super helpful, mizzao:sharejs is in demand for 0.9 and I'm trying to avoid creating some super hacky solution.

@glasser

This comment has been minimized.

Copy link
Member

glasser commented Sep 6, 2014

I reopened and renamed #1193. I'm not sure what other specific things you're looking for, other than just generally having more flexibility in what build plugins are allowed to do. We're aware that our build system only has a limited number of extension points and plan to increase them over time as we see what things our users are forced to hack around :)

#2488 was a very specific one line bug that we fixed due to your helpful report.

@glasser glasser closed this Sep 6, 2014

@mizzao

This comment has been minimized.

Copy link
Contributor Author

mizzao commented Sep 6, 2014

I don't think #1193 is asking for the same thing; it is for clients to be able to load assets of a package. I'm asking, on the server, for the package to be able to access the files under itself.

I'm trying to point out what I'm trying to do that needs to be extensively hacked around. I was hoping that we'd be able to have a discussion about what the package control format can support in the future.

@fix

This comment has been minimized.

Copy link

fix commented Sep 17, 2014

+1

1 similar comment
@ksopyla

This comment has been minimized.

Copy link

ksopyla commented Sep 22, 2014

+1

@tanis2000

This comment has been minimized.

Copy link

tanis2000 commented Sep 24, 2014

Any news on this one? Packages like Nemo64/meteor-bootstrap#5 are kind of stuck without being able to access the assets of the package itself during build time.

@craig-l

This comment has been minimized.

Copy link

craig-l commented Sep 29, 2014

+1

1 similar comment
@aaronjudd

This comment has been minimized.

Copy link

aaronjudd commented Oct 1, 2014

👍

Slava added a commit that referenced this issue Nov 1, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.