- NodeTools: Node.JS Stack
- Quick Start To NodeTools
- TrapCSS: NodeTools Tutorial
- TrapCSS 2: Advanced NodeTools
- Web Development With NodeTools
- Babel: When Open Source Is Not Free Sofware
- Discussion for NodeTools
NodeTools: A Complete Node.JS Development Stack
The key focus of NodeTools is to reduce the number of repetitive operations to the minimum, while allowing the developer to keep her personal style of programming. We're not trying to tell you how to organise source code, or how to code. We only want to automate those operations that take a large amount of time, and provide tools for the best developer experience.Packages' modularity is in the core of NPM infrastructure. It's great that everything can be split by package, including simplest functions. But it usually takes time to initialise those packages and repositories for them. It's really time consuming, but not with the package bootstrap from NodeTools. After setting it up locally with your GitHub developer key, you'll be able to generate new packages from our, or your own GitHub templates in a matter of seconds, and use the freed time wisely to produce more amazing code. MNP1.1.8
Traditionally, packages have been transpiled while their dependencies linked dynamically via the dependencies field in package.json, which means they are pulled when the package is installed. Although possible, static linking was not a standard and required running WebPack on packages, which is more of a web bundling tool. NodeTools for the first time ever allows to properly compile Node.JS packages using Closure Compiler from Google, so that a single, optimised output file is produced where dependencies are linked statically.Static linking means that the dependencies can be moved into devDependency field so that other developers will be more willing to install your package. By reducing the number of dependencies to bare minimum, the installation time increases, and packages look more like finished software products, instead of raw collection of functions put together from other libraries. You still have to do the job of annotation of types and fixing type errors, as the compiler expects code to adhere to certain JSDoc standard. Depack1.1.2
The advantage of TypeScript is that it provides the means for auto-completions that are required for great developer experience, and are pretty much a must for a successful package. Maintaining JSDoc has been harder, and other software like VSCode contains bugs that prevent proper working of JSDoc. But in NodeTools, this problem has been approached in a novel way: the type information is kept in XML files where interfaces and types are described. This allows to:
- generate and maintain JSDoc automatically from the single source of truth;
- create externs for the compiler as they are necessary for compilation of packages that are published for external consumption;
- embed type information into documentation in form of tables.
Moreover, the standard approach to documentation is to copy the source code and its output into the README file. However, such method is not robust because as the code changes, examples might become outdated and obsolete. Also it takes a lot of time to tediously re-run examples and manually cope the result they produce. A much better technique is to compile documentation using documentation engine.This advanced strategy allows to to keep source documentation split by files in a separate directory, and put it together using a single command. It will let you to save examples in separate files, while embedding them into README automatically, as well as forking them and inserting the output automatically also. As a bonus, you will be able to rename your imports, so that instead of saying import pckg from '../src', examples will say import pckg from 'pckg' which is ready to be copied by your users.
On top of that, our documentation tool supports watch mode with automatic push to remote repository, so that any change to docs will almost instantly be uploaded online so that you can see how changes look. There's also support for GitHub wiki pages that are now really easy to maintain, as you can create a submodule in your project, and just compile wiki pages into there.Documentary1.37.1
Quality assurance is just as important as the implementation itself. It's not only a process to make sure that code works, but a process that allows for development itself: the tests are the entry point to the program (otherwise, where do you execute the source from?). Therefore, testing must be the area that receive maximum attention from developer tools.There's a unique approach to testing in NodeTools. Your tests will have a context, that is, a collection of test APIs that can be invoked from test cases. This means you can put all testing utilities required to run specs in a separate file, to be able to keep test suite files nice and organised and be able to create as many test suite files are needed, without being contained by the fact that your testing utilities are scoped within beforeEach and afterEach blocks. Each test will have a test sandbox which is called a context, and its methods are accessed easily via JSDoc. Context testing provides the perfect environment for bespoke developer experience as you can publish your own contexts and reuse them across packages.
To get help, you can:
- File an issue on GitHub⭐️ 1. Don't be shy if you have a question, issues are free and there's not problem with opening a new one whenever you feel like it.
- Join Gitter chat which is always monitored so that you can receive the response as soon as possible.
- Participate in discussion by creating a new comment on this website and making sure to tick the "subscribe" box to get notified via web-push when you receive a response.
- Transfer financial contribution on OpenCollective to receive one-to-one support in helping to upgrade your packages to the stack, including Closure Compiler assistance. There's no prejudice to paid and unpaid support and we'll always seek to answer any questions ASAP using the channels above.