[Openembedded-architecture] Improving Node.js developer workflow

[Trevor Woerner]

Hi Henry,

On Tue 2016-11-15 @ 07:11:30 PM, Bruce, Henry wrote:
> I have a proposal for a theme for Yocto Project 2.3 development and it
> has been suggested that I post to this mailing list. In short it's
> about making life easier for Node.js developers by enhancing devtool
> and its supporting tools (e.g. recipetool). The rationale behind this
> proposal can be found at https://wiki.yoctoproject.org/wiki/Nodejs_Work
> flow_Improvements which also includes more details on the proposal and
> some opens. 
> 
> I'd appreciate feedback on whether people think that Node.js merits
> this attention. I'd also be interested to know what level usage drives
> the transition of recipes from meta-oe into core.
> 
> Thanks for your time,

Thank you (and thank you Intel ;-) for taking this on.

The higher-ups where I work have decided that not only do they want to switch
to an embedded Linux platform, but, at the same time, that all development
will be done in Node.js[1]. So everything that you (and others) are doing in this
space is something that I'm going to be studying very closely over the next
little while. For the time-being, however, I'm new most of this.

I don't always get around to reading the mailing lists every day, so feel free
to contact me directly (if you wish) to be your outside tester if I'm taking
too long to reply to something on the public mailing list or if you've done
something new and are looking for feedback.

I'll be building images and supporting the devices. Their hope is that
a developer can do all their work on a any OS and not have to do any
cross-compiling.

My impression is that even the simplest node 2-liner requires, at a minimum,
about 400 npm modules, most of which can simply be copied to the target and
interpreted via the javascript interpreter, but some of which may require
cross-compiling.

My guess is that I need to get a list from the developer of the dozen or
so npm modules he's using directly, and that somehow the build system will
includes those in the image, plus the dozen submodules each of those depend
on, then the dozen subsubmodules each of the submodules depends on, etc.? Or
maybe I just need his grunt file (or equivalent?).

https://wiki.yoctoproject.org/wiki/Nodejs_Workflow_Improvements

Just like with the kernel, I think each Yocto release should include the
current nodejs release, an LTS release, and possibly a bleeding-edge release.
Maybe the LTS should be the default?

To me it doesn't matter where the recipes are found; whether they're in their
own layer, in meta-oe, or oe-core. If however it's managed is properly
maintained, I have no reason to prefer one over the others.

Maybe hold off on the bugzilla category for now. I think it's too early to
tell just yet how much staying power it has, especially in this field
(emebedded linux image building).

I don't think a node-specific image is required. I think most people can
CORE_IMAGE_EXTRA_INSTALL what they need? I'm not opposed to it, but if the
only difference between it and, say, core-image-minimal is two packages then
just let the user add them for themselves. Besides, some people will be want
to start with core-image-minimal, others prefer core-image-full-cmdline,
others yet may want core-image-sato. Which one of these would be the basis for
core-image-nodejs? Easier to just let the user add them themselves. Maybe this
is a distro decision?

I'm surprised by the "once project is working on target" question. Would you
expect node development to be carried out on the target itself? Wouldn't it be
better to handle this sort of thing from the point of view of a grunt or
yeoman file? My gut feeling is to let the developer use whatever they want,
then they provide either a grunt file, a yeoman file (or whatever other node
project management xml goodness comes along) or they just provide a list of
top-level npm modules (and their versions?), that gets specified in a recipe,
and bitbake handles the rest. If Paul is looking for more devtool cleverness
(as if devtool wasn't clever enough already!) maybe it could examine the
toplevel "server.js" file and parse out the "requires" statements to build up
its own list of toplevel npm module requirements? Maybe the name of the
top-level js file could be specified in the recipe? Or devtool could look for
it itself?

And the last question seems too big for even an opinion :-)