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

Don't use package.json to load dependencies. #279

Open
jorgebucaran opened this issue Jun 14, 2017 · 4 comments
Open

Don't use package.json to load dependencies. #279

jorgebucaran opened this issue Jun 14, 2017 · 4 comments

Comments

@jorgebucaran
Copy link
Contributor

jorgebucaran commented Jun 14, 2017

This was an early decision choice which I felt would help reduce boilerplate, and it does. On the other hand, it's magic.

EDIT: Grammar.

module.exports = {
  *lint(fly) {
    yield fly.source(js).xo({ esnext: true })
  },
  *scripts(fly) {
    yield fly.source(js).babel({ presets: ["es2015"] }).target(`${dist}/js`)
  },
  *styles(fly) {
    yield fly.source(sass).sass({ outputStyle: "compressed" }).autoprefixer().target(`${dist}/css`)
  },
  *build(fly) {
    yield fly.parallel(["lint", "scripts", "styles"])
  }
}

If you already know the API, you'd know that .source and .target are core and that .sass or .xo must be plugins, but what about plugins like .concat.

@lukeed
Copy link
Owner

lukeed commented Jun 27, 2017

I've been thinking about this as a far-away possibility. I'm developing other aspects of the approach first to see if this arises as a necessity.

Will revisit in the future 👍

@jorgebucaran
Copy link
Contributor Author

@lukeed Have you thought about this? I was never able to find a good compromise, so I did nothing. Maybe your current approach is better, it works. Feel free to close.

@lukeed
Copy link
Owner

lukeed commented Dec 12, 2017

Hey, I have a lot of stuff in the works, I just haven't had time to refine it and publish it yet.

The only way to do this outside of package.json is with try-catch and require.

Honestly, I've never heard of someone having an issue and trying to bypass package, so this is a really low priority... I leave it open just to think about every once in a while lol

@jorgebucaran
Copy link
Contributor Author

I remember not liking this approach, the idea of using pkg.json to store configuration, because I disliked it when I was working with ember-cli and their rampant use of pkg.json similarly. But that was an extreme example, and it's not like you are abusing it either.

Yeah, I know what you mean :p

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants