V4.0.0

[Ceasar Doyle]

Thecollaborators of the Node.js project and the members of the Node.js Foundation are proud to offer v4.0.0 for general release. This release represents countless hours of hard work encapsulated in both the Node.js project and the io.js project that are now combined in a single codebase. The Node.js project is now operated by a team of 44 collaborators, 15 of which form its Technical Steering Committee (TSC). Further, over 100 new individuals have been added to the list of people contributing code to core since v0.12.7.

Node.js v4.0.0 contains V8 v4.5, the same version of V8 shipping with the Chrome web browser today. This brings with it many bonuses for Node.js users, most notably a raft of new ES6 features that are enabled by default including block scoping, classes, typed arrays (Node's Buffer is now backed by Uint8Array), generators, Promises, Symbols, template strings, collections (Map, Set, etc.) and, new to V8 v4.5, arrow functions.

Over the past year thanks to donations from companies such as Rackspace, DigitalOcean, Scaleway, miniNodes, Voxer, Joyent, CloudFlare, ARM Holdings, and individuals from the community, we've built an amazing test cluster that includes an impressive line-up of Linux variants, OS X, Windows, FreeBSD and SmartOS. New to Node.js, we also have first-class support for ARM processors. Our test suite must be continually passing on ARMv6, ARMv7 and the new 64-bit ARMv8 processors. So Node.js is officially ready for use by hobbyists and ARM server users alike.

Node.js v4 also brings a plan for long-term support (LTS) and a regular release cycle. Release versioning now follows SemVer, so expect increments of both minor and patch version over the coming weeks as we fix bugs and add features. What we won't be doing within the v4.x branch is adding breaking changes.

However, we have mapped a quick initial path to our first LTS version which will come in October. At the same time, a new v5.x branch will be cut and we will begin making a new series of Stable releases available, starting with v5.0.0. These will likely contain a new version of V8 and any breaking changes that may be necessary. The v4.x line of releases will continue for an additional 18 months in LTS, with a focus on stability and security and no unnecessary additions in functionality. Beyond that, v4.x will move in to Maintenance for an additional 12 months where it will continue to receive attention for critical bugs and security fixes.

In parallel, we will be branching a new Stable line of releases every 6 months, one in October and one in April each year. Stable lines will be made up of regular releases as development continues, expect minor and patch version bumps every week or two from these. Every second Stable release line will continue life in LTS form by the time October comes around. This means that there will be overlapping LTS branches being maintained throughout the year, each receiving attention for a total of 30 months (LTS plus Maintenance). We believe that the Stable and LTS cycles provide the room for the project to continue its innovation and stay with the cutting-edge of JavaScript while also serving the need for predictable long-term stability and security demanded by the growing line-up of enterprise users proudly adopting Node.js as a key technology; some of who already count themselves as members of the Node.js Foundation.

As always with a major release, we don't expect the adoption of Node.js v4 to be painless. It will take time to adapt, particularly as compiled add-ons catch up with the new version of V8 (hint: see NAN for our official solution to the compatibility problem). Thankfully, the io.js v3.x series of releases have given many add-on authors a chance to prepare their code for Node.js v4, so much of the npm ecosystem is ready today.

An initial list of breaking changes between v0.12 and v4 can be found on the LTS wiki, in the coming days we will continue to populate both this wiki and the core wiki with documentation regarding the changes you should be aware of.

This list of changes is relative to the last io.js v3.x branch release, v3.3.0. Please see the list of notable changes in the v3.x, v2.x and v1.x releases compiled in unified CHANGELOG for a more complete list of changes from 0.12.x. Note, that some changes in the v3.x series as well as major breaking changes in this release constitute changes required for full convergence of the Node.js and io.js projects.

We recommend that you only upgrade to Stencil v4 from Stencil v3.If you're a few versions behind, we recommend upgrading one major version at a time (from v1 to v2, then v2 to v3, finally v3 to v4).This will minimize the number of breaking changes you have to deal with at the same time.

Starting with Stencil v4.0.0, the default configuration values have changed for a few configuration options.The following sections lay out the configuration options that have changed, their new default values, and ways to opt-out of the new behavior (if applicable).

In the example above, "@utils" would be mapped to the string "src/utils/index.ts" when TypeScript performs type resolution.The TypeScript compiler does not however, transform these paths from their keys to their values as a part of its output.Instead, it relies on a bundler/loader to do the transformation.

The ability to transform path aliases was introduced in Stencil v3.1.0 as an opt-in feature.Previously, users had to explicitly enable this functionality in their stencil.config.ts file with transformAliasedImportPaths:

Starting with Stencil v4.0.0, this feature is enabled by default.Projects that had previously enabled this functionality that are migrating from Stencil v3.1.0+ may safely remove the flag from their Stencil configuration file(s).

For users that run into issues with this new default, we encourage you to file a new issue on the Stencil GitHub repo.As a workaround, this flag can be set to false to disable the default functionality.

Introduced in Stencil v2.18.0, transformAliasedImportPathsInCollection is a configuration flag on the dist output target.transformAliasedImportPathsInCollection transforms import paths, similar to transformAliasedImportPaths.This flag however, only enables the functionality of transformAliasedImportPaths for collection output targets.

Starting with Stencil v4.0.0, this flag is enabled by default.Projects that had previously enabled this functionality that are migrating from Stencil v2.18.0+ may safely remove the flag from their Stencil configuration file(s).

Prior to Stencil v4.0.0, components could be compiled from TSX to JS in the browser.This feature was seldom used, and has been removed from Stencil.At this time, there is no replacement functionality.For additional details, please see the request-for-comment on the Stencil GitHub Discussions page.

In Stencil v3.0.0, we announced the deprecation of IE 11, pre-Chromium Edge, and Safari 10 support.In Stencil v4.0.0, support for these browsers has been dropped (for a full list of supported browsers, please see our Browser Support policy).

The extras.__deprecated__dynamicImportShim option caused Stencil to include a polyfill forthe dynamic import() functionfor use at runtime.This field should be removed from a project's Stencil configuration file (stencil.config.ts).

The extras.__deprecated__shadowDomShim option would check whether a shim for shadowDOMwas needed in the current browser, and include one if so.This field should be removed from a project's Stencil configuration file (stencil.config.ts).

The enableCacheStats flag was used in legacy behavior for caching, but has not been used for some time. Thisflag has been removed from Stencil's API and should be removed from a project's Stencil configuration file (stencil.config.ts).

Stencil no longer supports Node 14.Please upgrade local development machines, continuous integration pipelines, etc. to use Node v16 or higher.For the full list of supported runtimes, please see our Support Policy.

Since the LED strip works this seems to be a settings issue. Could someone please point me in the direction? Or is it simply so that v4.0.0 of the D1 Mini is not supported (the homepage says that the latest version of the hardware is 3.1.0)?

Hi, I am having a similar issue tonight with my d1 mini controller. The symptoms are similar of those of yours with random lighting like if the led is having a stroke. I tried to diagnose the issue and I found that the voltage of the gpio 2(d4 pin, next to gnd) is very low, like 0.056v on multimeter and no current flow. My multimeter works as it correctly shows the voltage of the 5v pin on the d1 mini as 5v.

Strangely, pressing the reset button does yield the expected 3.3v and even more strangely when I turn off the d1 mini using the web controller, gpio 2 also outputs 3.3v. I did not have enough time to test further as I had to go somewhere.

So far, I have tried erasing the data of the d1 mini and even flashing it with the stable version of wled rather and a beta release and version 1.14 or whatever was also not showing on my browser Chrome.

I have yet to try the other pin like the tx pin which I believe is gpio1 but I plan to try it as my homemade board on a perforated board has another terminal for data out for tx connected to logic level booster.

What are the manufacturer docs on that level shifter?

It looks suspiciously like the I2C type units that are known to be too slow to work well with addressable LED data streams. YouTube videos on very often a poor source for reliable information.

I would suggest something based on a 74AHCTxxx device.

You could even try without a shifter at all as long as you keep the ESP very close to the strip.

You might also try a different GPIO pin, make sure you configure WLED to match what you choose.

3a8082e126