threepointone / ratpack

ready. set. go!
197 stars 10 forks source link

Browserify transforms #3

Closed rreusser closed 7 years ago

rreusser commented 7 years ago

It looks like https://github.com/webpack/transform-loader would work fine, which means there maybe just needs to be some means of adding webpack config. Perhaps the nearest config file (package.json? webpack.config.js?) would be the place to hook up this and, more generally, whichever particular tools your project might need.

threepointone commented 7 years ago

Yes, trying to figure out a convention for this, good idea.

An idea I had was using an inline pragma, so you could write this at the top of the file // @loader { ... } And it would 'just work'. Thoughts?

rreusser commented 7 years ago

What about a strategy like https://www.npmjs.com/package/pkg-up ? That way files in a directory would just inherit from the nearest setup, which could avoid having to configure each file while still being able to manage different contexts.

Edit: I don't use webpack too much. Is json adequate or does it need to be js?

threepointone commented 7 years ago

Yeah, merging webpack configs is quite the task, which is why I'd like to manage access to it. I'm also thinking of a preferences pane to manage/configure libs ratpack 'globally'

rreusser commented 7 years ago

Makes sense. Thanks for encouraging feedback! Having made my interest known, whichever direction you choose to go is great! If too much customizability turns it into a 800 lb gorilla of a tool which no one likes to use, then yeah, don't hesitate to limit the scope even if it may restrict it's applicability as a tool that solves every conceivable use-case. 😄

rreusser commented 7 years ago

Specific feedback though: the pragma approach isn't bad. I can see the desire to send someone a single file with all the config necessary to get off the ground. Maybe something like json-front-matter instead of a new syntax? An advantage is that in-file json front-matter could get deep-merged into and override what was found in the the package.json. That way there's no new syntax to learn, it's all json, and it can be inherited from a package.json or specified in-file. The only downside is that it's then not valid javascript by itself. So then what about optionally starting files with:

/*{
  "loaders": [
     ...
  ]
}*/

or perhaps:

/*{{{
  "loaders": [
     ...
  ]
}}}*/
threepointone commented 7 years ago

took the json advice to heart, follow along on #15

threepointone commented 7 years ago

pending docs, this will go out in the next release, closing for now.