It is with great pleasure that I announce the release of Trio v6.1.0.
Highlights
This release of Trio continues to improve upon the integration of external processes (e.g. npm scripts, Grunt, Webpack, Parcel, Browserify) with Trio's build & release workflows.
This Is A Minor Release
Issue #137: Refactor Trio to use BrowserSync's watcher to watch for changes to the public build folder and to respond to "change" events by reloading the browser.
Issue #138: Auto increment the port number that BrowserSync uses since BrowserSync no longer does so when the default port number (3000) is being used.
Changelog
Please see the changelog for details.
It is with great pleasure that I announce the release of Trio v6.0.4.
Highlights
This Is A Patch Release
Issue #135: Upgrade Node to v14 LTS and upgrade Trio's dependencies.
Issue #134: Module lib/generator/sassRender.js must call toString() when writing the postcssResult.map to a file.
Issue #136: A circular dependency discovered in lib/utils/getFileModifiedTime.js after upgrading Node to v14 LTs and Trio's dependencies.
Changelog
Please see the changelog for details.
It is with great pleasure that I announce the release of Trio v6.0.3.
Highlights
This Is A Patch Release
This release addresses issue #133 and now refreshes the browser whenever a hidden file is added, changed and deleted.
Changelog
Please see the changelog for details.
It is with great pleasure that I announce the release of Trio v6.0.2.
Highlights
This Is A Patch Release
This release addresses issue #131 and now checks if the source folders actually exists prior to copying their files.
Changelog
Please see the changelog for details.
It is with great pleasure that I announce the release of Trio v6.0.1.
Highlights
This Is A Patch Release
This release address a bug that was introduced with Trio v6.0.0 and its support for user created folders in the root/source/ folder. These folders, if not ignored, can pollute Trio's metadata and interfere with Trio's build and release workflows. This release corrects that by ignoring these folders which users now identify through the new ignore configuration property.
Changelog
Please see the changelog for details.
It is with great pleasure that I announce the release of Trio v6.0.0.
Highlights
An Improved Release Workflow That Now Supports JavaScript Bundling
Prior to Trio v6.0.0 cache busting was initiated by running the command trio release -b. The problem is that this didn't allow the developer to run their NPM package.json scripts, such as those that might bundle their JavaScript modules, before they cache busted the site. Removing the -b option from the trio release command and implementing a standalone trio cachebust command that can be called after running trio release corrects this and allows for an "open" workflow, such as using NPM scripts in your package.json file
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"parcelBuild": "parcel watch source/jsBundle/main.js --no-cache --out-dir public/scripts --public-url /scripts/",
"trioBuild": "trio b -I",
"build": "concurrently --kill-others \"npm run trioBuild\" \"npm run parcelBuild\" ",
"release": "trio r && parcel build source/jsBundle/main.js --no-cache --out-dir release/scripts --public-url /scripts/ && trio cachebust -m && trio s -r"
},
for development builds
# run npm script to bundle JavaScript into public/scripts folder
npm run build
and for release builds.
# run npm script to bundle JavaScript into release/scripts folder
npm run release
If your site uses a JavaScript bundler (e.g. Parcel, Browserify, Webpack) to package its runtime JavaScript then do not host those modules in root/source/scripts. Instead, create a new folder in root/source, for example jsBundle, and host them there. Please see Project Structure for details.
New CSS Source Map Generation Options
Trio now offers sensible configuration options for controlling the generation of CSS map files for both development and release builds.
From within trio.json you can now configure source map generation using the following:
"sassSourceMaps": {
"development": [true | false],
"release": [true | false]
}
Both development and release builds default to true.
Improved Cache Busting, A Breaking Change
Trio v6.0.0 has upgraded its toolchain to use version v1.0.0 of the browser cache buster Buster, which eliminates a bug that would result in URLs being hashed twice. This would occur when a URL points to a file whose file name is used in part in another file's name. This naming convention is common for JavaScript map files and CSS map files.
For example, when hashing the file names for the files [mybundle.js] and [mybundle.js.map] Buster would ultimately hash [mybundle.js.map] as [hash-hash-mybundle.js.map].
Please note that beginning with Buster v1.0.0, your site's internal URLs are required to be site releative. This requirement is a breaking change from previous versions of Buster. What does this mean for your existing Trio projects that are using Trio's cache busting? Existing projects' internal URLs that aren't already site relative will need to be converted. Please see Linking Conventions and Buster's documentation for details.
Changelog
Please see the changelog for details.
Trio v5.0.0
It is with great pleasure that I announce the release of Trio v5.0.0.
Trio is now using Dart Sass as its Sass Compiler
Trio is no longer using Node Sass as it and Lib Sass have been deprecated. Please note that this is a breaking change that could impact your stylesheets (Please see https://sass-lang.com/blog/libsass-is-deprecated#how-do-i-migrate for more information).
Trio v4.2.0
It is with great pleasure that I announce the release of Trio v4.2.0.
Trio now ignores and reports fragments that do not have front matter defined.
Prior to v4.2.0, fragment files that did not have front matter generated errors that were confusing and unnecessary (as far as the user is concerned). These fragments are now reported to the console but otherwise ignored during the build process.
Trio v4.1.0
It is with great pleasure that I announce the release of Trio v4.1.0.
Trio now supports callbacks declared on tags that are replaced by include and fragment content.
Prior to v4.1.0, tag-based callbacks declared on tags that are replaced by an include's or a fragment's content are never registered and therefore never called. Trio V4.1.0 corrects this omission and now supports tag-based callbacks on these tags.
Support for these callbacks will allows you to directly target these tags in your tag-based callbacks using the callback's $tag parameter.
Please note that this new behavior doesn't impact how Trio outputs these tags for development and release builds. As always, when building for development, Trio will still comment out these tags in the generated HTML document, and when building for release, Trio will not output these tags in the generated HTML document.
While you are enjoying the recently released Trio v4.0.0 we want you to know that Trio v4.1.0 is already in the testing phase and will be released shortly.
Although it wasn't explicitly stated in the documentation, tag-based callbacks that are declared on tags that are replaced by an include's or a fragment's content are never registered and therefore never called. Trio V4.1.0 corrects this omission and now supports tag-based callbacks on these tags.
Support for these callbacks will allows you to directly target these tags in your tag-based callbacks using the callback's $tag parameter.
Please note that this new behavior doesn't impact how Trio outputs these tags for development and release builds. As always, when building for development, Trio will still comment out these tags in the generated HTML document, and when building for release, Trio will not output these tags in the generated HTML document.
If you would like to be notified when Trio v4.1.0 drops then please consider following @gettriossg on Twitter.
