4 ms·

> So many things to keep in mind, so many dependencies, so very many points of failure. If just one of these libraries is abandoned, or has a breaking change, y

by insin 10y ago

> So many things to keep in mind, so many dependencies, so very many points of failure. If just one of these libraries is abandoned, or has a breaking change, your entire development environment is dead. Is this the current state of frontend web dev, or are these guys just overdoing it for the sake of the tutorial? This tutorial is trying to guide you over the initial hump with the tooling by letting you hit the issues you'd hit if you were learning it on your own (like dependencies which need tweaks to your Webpack config to work properly like sinon, enzyme, moment...). They _could_ have handed you a completely pre-baked config and got to Hello World in step 2, but you wouldn't have learnt anything about the tooling. In terms of a development library you depend on being abandoned or broken, I've extracted my React development environment out into a separate npm package [1] and it's still using Babel 5, auto-prefixer loader (which is deprecated in favour of using PostCSS directly) and is working around every version of babel-runtime v5 after 5.8.29 containing a broken version of an important module. By pinning your dependencies, you can keep using old or deprecated versions of things until you're ready to upgrade, and by managing development tools in an external module you can upgrade your projects when you're good and ready by bumping a version number. If you do that, starting a React project (or any other project which gets tool-heavy for apps of any size) can be a 1-step proceess you can have an understanding of the tooling, and you have a way to keep it manageable over time. [1] https://github.com/insin/nwb#nwb https://github.com/insin/nwb#nwb

jjnoakes 10y ago
I am not a front end dev so this is a serious question. The new shiny seems to be using dependencies straight from git and vendoring them. Presumably new versions come out because they fix bugs or security issues. How do you keep your projects up to date? Do you manually check every dependency in your project once in a while? Do you have some automation which alerts you to security issues in a dependency of yours? If you decide you need to stay on an older version, is someone backporting fixes? Is there a curated set of packages that are known to work together? When an update comes in, do you audit it to make sure nothing malicious makes it on to your systems? Or does one have to wait until this stuff stabilizes and baked it's easy into linux distributions before one gets these nice features? (Which basically isn't easy to do with how fast the landscape is evolving). I'm curious about solutions to these problems.
- insin 10y ago
  > The new shiny seems to be using dependencies straight from git and vendoring them. That's news to me, it's all npm and node_modules/ as far as I can see. > How do you keep your projects up to date? Do you manually check every dependency in your project once in a while? Do you have some automation which alerts you to security issues in a dependency of yours? You can get https://greenkeeper.io/ https://greenkeeper.io/ to watch your project and its dependencies - it creates Pull Requests to update dependencies with details of what changed in the description, and all the usual PR stuff like running whatever CI you've configured happens as a result of creating it. If I don't have Greenkeeper set up (the PRs can get a bit noisy), I just run npm outdated --depth=0 any time I'm poking about in a project. > If you decide you need to stay on an older version, is someone backporting fixes? Depends entirely on the maintainers of that project. Babel 5 has had a couple of things backported, like support for Flow annotations, for example. > Is there a curated set of packages that are known to work together? Not curated as such, but you can just look at what people are successfully using and sharing, and tools people are creating. nwb is effectively my own curated package of development tools pre-wired together. > When an update comes in, do you audit it to make sure nothing malicious makes it on to your systems? I usually check the diff between the release tags/changelogs between what I'm updating to before, but not specifically security auditing. > Or does one have to wait until this stuff stabilizes and baked it's easy into linux distributions before one gets these nice features? That's not going to happen :)

by insin 10y ago

jjnoakes 10y ago

I am not a front end dev so this is a serious question. The new shiny seems to be using dependencies straight from git and vendoring them. Presumably new versions come out because they fix bugs or security issues. How do you keep your projects up to date? Do you manually check every dependency in your project once in a while? Do you have some automation which alerts you to security issues in a dependency of yours? If you decide you need to stay on an older version, is someone backporting fixes? Is there a curated set of packages that are known to work together? When an update comes in, do you audit it to make sure nothing malicious makes it on to your systems? Or does one have to wait until this stuff stabilizes and baked it's easy into linux distributions before one gets these nice features? (Which basically isn't easy to do with how fast the landscape is evolving). I'm curious about solutions to these problems.

insin 10y ago
> The new shiny seems to be using dependencies straight from git and vendoring them. That's news to me, it's all npm and node_modules/ as far as I can see. > How do you keep your projects up to date? Do you manually check every dependency in your project once in a while? Do you have some automation which alerts you to security issues in a dependency of yours? You can get https://greenkeeper.io/ https://greenkeeper.io/ to watch your project and its dependencies - it creates Pull Requests to update dependencies with details of what changed in the description, and all the usual PR stuff like running whatever CI you've configured happens as a result of creating it. If I don't have Greenkeeper set up (the PRs can get a bit noisy), I just run npm outdated --depth=0 any time I'm poking about in a project. > If you decide you need to stay on an older version, is someone backporting fixes? Depends entirely on the maintainers of that project. Babel 5 has had a couple of things backported, like support for Flow annotations, for example. > Is there a curated set of packages that are known to work together? Not curated as such, but you can just look at what people are successfully using and sharing, and tools people are creating. nwb is effectively my own curated package of development tools pre-wired together. > When an update comes in, do you audit it to make sure nothing malicious makes it on to your systems? I usually check the diff between the release tags/changelogs between what I'm updating to before, but not specifically security auditing. > Or does one have to wait until this stuff stabilizes and baked it's easy into linux distributions before one gets these nice features? That's not going to happen :)