next #29
Comments
Heya! Just not force the things too fast. You should see what's the community and how big it is. Invest some time to research, because this seems like big change. I'm agree with the monorepo and probrably with the renaming, since most of the packages are at your accont and this org. What means "no more presets"? And why "console.log is not the default reporter"? What will be the default reporter? If the rename happen, I suggest to start it as separate project OR release it as Start v6. If there's no impact on the community and actually don't have any let start v5 be last version and start a new project from scratch without touching start. |
It's only about "no start-start-preset", because I just don't need it anymore with monorepo.
Nothing by default? I mean you have to choose something and pass it as an argument to Runner (simple, pretty, whatever), default
Actually that's the decision I tend to. Just not to break literally everything with one move. Make a monorepo, make breaking changes, major bump start to v6 and major bump every task package. Also I want to rename |
Agree. Sounds good. |
Seems like the best option, I also don't know what I would rename |
Forgot to mention that there is also https://github.com/iamvdo/pleeease (edited) |
alright, just got "start" username (so |
Super 🎉 As about the tasks. Are they curried? Like all of these are equivalent export default (options) => function myTask(input, log, reporter) {
console.log('input:', input);
log('hey from My Task!');
console.log('original reporter:', reporter);
return Promise.resolve('My Task output');
} second variant export default (options) => function myTask(input, log) {
return (reporter) => {
console.log('input:', input);
log('hey from My Task!');
console.log('original reporter:', reporter);
return Promise.resolve('My Task output');
}
} third export default (options) => function myTask(input) {
return (log, reporter) => {
console.log('input:', input);
log('hey from My Task!');
console.log('original reporter:', reporter);
return Promise.resolve('My Task output');
}
} and export default (options) => function myTask(input) {
return (log) => {
return (reporter) => {
console.log('input:', input);
log('hey from My Task!');
console.log('original reporter:', reporter);
return Promise.resolve('My Task output');
}
}
} |
Looking over the new code: no. But would be good to support it. |
@deepsweet one more thing that may be good to add is, don't sure how to name it, the the eslint rule config
for example your export const build = () => start(
env('NODE_ENV', 'production'),
files('build/'),
clean(),
files('lib/**/*.js'),
read(),
babel(),
write('build/')
); to this one export const build = () =>
start(
env('NODE_ENV', 'production'),
files('build/'),
clean(),
files('lib/**/*.js'),
read(),
babel(),
write('build/')
) which is a bit uglier for my taste (i hate this new line return, like in Python and Ruby). All this can be fixed if the export const start = Start(reporter())
const _start = (...args) => () => start(...args)
export const build = _start(
env('NODE_ENV', 'production'),
files('build/'),
clean(),
files('lib/**/*.js'),
read(),
babel(),
write('build/')
) So probably we can add second argument to the initial Start call, which would be boolean, so // returns as what currently returns (a function which accept tasks)
const start = Start(reporter()) and if we pass const start = Start(reporter())
const _start = Start(reporter(), true)
export const bar = () => start(
one,
two,
three
)
export const foo = _start(
one,
two,
three
) |
Task internals are kinda not exposed to the user land, that's why I was thinking about to simplify tasks API a bit because it's used only by Start itself. Will post an update here soon, I have a bunch of new ideas since March :)
These arguments are really useful when they available for the entire scope: export const makeES = (packageName) => start(
files(`packages/${packageName}/es/`),
clean(),
files(`packages/${packageName}/src/**/*.js?(x)`),
read(),
babel(babelConfig),
rename((file) => file.replace(/\.jsx$/, '.js')),
write(`packages/${packageName}/es/`)
); Also it will play very nice with the next version of const build = (packageName) => start(
parallel('makeES, makeLib')(packageName)
);
🙈 |
I know 😆 I wanted them. But in most cases may be not needed. |
So here is my latest ideas:
|
It's not a hack and is enough in most cases. Otherwise you can use export default (options) => plugin('foo bar plug', (input, log, reporter) => {})
// if not a string, then fallback to `get-fn-name`
export default (options) => plugin((input, log, reporter) => {}) evenmore, this export default plugin('Oh Buble Plugin', (input, options, log, reporter) => {
if (options.foo) {
log('woohoo')
}
}) usage import bublePlugin from '@start/buble'
export const build = start(
buble({ foo: 'bar' })
) where, of course this |
Even more clean and beauty may be if we enforce conventions, using the destructuring. The destructuring js feature is just freaking awesome and amazing, exactly because these two things:
So probably it will be the best if our signature is export default plugin('Oh Buble Plugin', (input, { options, log, reporter }) => {
if (options.foo) {
log('woohoo')
}
}) Haha, and so, no need for currying support 🤣 |
THIS 🔥 export default plugin('Oh Buble Plugin', ({ input, options, log, reporter }) |
Exactly! Exactly this was typing in the editor, because i'm working on 40 lines version :P |
What about Start to accept emitter instead of |
💎 |
Great! I'll PR with my idea for |
|
Anyway, it's written from scratch, so i don't need a branch :D I'll create new branch anyway ;] Just to see it in files and not in issue codeblocks. :) |
@deepsweet Looking fwd for the new changes. Need any help? I was looking for a module that does pretty much what you are doing before I start building my own. Do you have an ETA or need some help? |
@radum I'm expecting |
Plugins are not important for me right now. The fact that I can use functions that return a promise as |
Hey @deepsweet start's great to hear! Sorry about the promotion, but someone may be interested in hela too. It's is similar, but takes a bit different path by using just execa and executing the commands, instead of using task's/package's APIs, which requires a lot small boilerplate. You can see I invest heavily in it. And everything just started after complete rewrite of Start (again around 30-40 lines). Btw... i have it somewhere locally and it was meant to be landed as PR here to discuss. edit: (...after few seconds) damn, i reinstalled my machine last night and don't remember if i had it somewhere backedup in the github. edit2: The |
Hey @deepsweet, did you manage to finish this? I'm quite keen to see how the final Plugin code looks like. |
😿 |
@deepsweet I would gladly help to port the current plugins. For my own personal use and for my company, the concurrent and parallel plugins are the most important ones. But before I start we need the final version of the next release :P |
see master branch for current state – it's almost stabilized and all known API experiments are completed. I've been waiting for this since forever as well 🙏 there should be |
I've just published v0.1.0 of everything. |
Hey. I'm about to introduce next major version relatively soon, with simplified tasks API and better API for tasks runner itself. Some details from future
migration.md
:Start
Repositories
Start
became a monorepo.Pros:
start-start-preset
babel-preset-start
Cons:
Runner
With this naming our core concept became much more clear: there are
tasks
and tasksrunners
. You have to wraptasks
withrunner
."External" input
runner
itself is another function in which you can pass an "initial" input:So no more
start-input-connector
:And
start-watch
became really beautiful:Tasks
Refactoring
Tasks were slightly simplified:
So in the simplest case
task
is just a single named function which should return a Promise.Reporters
Default reporter
console.log
is no more a default reporter for Runner.Refactoring
Reporters were splitted into composed functions:
@effervescentia @tunnckoCore @laggingreflex @nikolay @eisisig I was thinking about scoped packages like
@start/runner
,@start/clean
and so on. But unfortunatelystart
username is already taken on NPM. So I wrote to the author – radio silence, wrote to NPM support – they can't help even with abandoned empty accounts...Rename the whole project? Or leave it as is with
start-
naming convention? I'm ok with both, but I need your opinion.yarn please build yarn please test
🤔
Pros:
0.1.0
versions for every packagepleasejs/please
as a main repoCons:
What do you think about
please
? The major changes described above will be implemented regardless this naming issue.The text was updated successfully, but these errors were encountered: