This tutorial is based on this repo and demonstrates how to integrate the bundling of your site's JavaScript runtime into Trio's build and release work flows. While this tutorial uses the bundler Parcel to create the JavaScript runtime you are free to use your JavaScript bundler of choice.
This tutorial is based on this repo and demonstrates how to integrate the bundling of your site's JavaScript runtime into Trio's build and release work flows. While this tutorial uses the bundler Parcel to create the JavaScript runtime you are free to use your JavaScript bundler of choice.
It is with great pleasure that I announce the release of Trio v6.1.0.
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.
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.
Please see the changelog for details.
It is with great pleasure that I announce the release of Trio v6.0.4.
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.
Please see the changelog for details.
It is with great pleasure that I announce the release of Trio v6.0.3.
This release addresses issue #133 and now refreshes the browser whenever a hidden file is added, changed and deleted.
Please see the changelog for details.
It is with great pleasure that I announce the release of Trio v6.0.2.
This release addresses issue #131 and now checks if the source folders actually exists prior to copying their files.
Please see the changelog for details.
It is with great pleasure that I announce the release of Trio v6.0.1.
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.
Please see the changelog for details.
It is with great pleasure that I announce the release of Trio v6.0.0.
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.
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.
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.
Please see the changelog for details.
I am very pleased to announce that the next release of Trio will provide the following enhancements:
Support for integrating your preferred JavaScript bundling tools (e.g. Parcel) into Trio's build and release processing.
New SASS configuration options for controlling CSS source map generation for both build and release processing.
Before Trio was even a project, the ability to cache bust a website generated by it was acknowledged as a major required feature that must be provided in the future project's toolchain. So the development of a cache-busting facility was begun which ultimately resulted in the delivery of Buster.
At the time of Buster's initial development it was decided that Buster was to serve two roles, one as a standalone utility and one as member of Trio's toolchain. As a standalone utility Buster would have to be dynamic enough to satisfy a variety of use cases that its users may require. However, as part of Trio's toolchain Buster would be used only to cache bust "in place", meaning that cache busting is applied directly to the files in the release folder and no ability to restore or reverse the actions of cache busting would be needed because that could be satisfied by merely rebuilding the project for release.
Since its initial release, Buster has become quite popular as a standalone utility and over time a pattern of its use as a standalone utility has emerged - the vast majority of its users are using Buster to cache bust their own projects "in place", just as how Trio internally uses Buster to cache bust its projects "in place".
With that revelation has come a decision to refactor Buster with the objective of simplifying its code base by removing all features that are not directly involved with cache busting "in place". The result will be a smaller and simpler code base that will be easier to maintain and which will be more in line with how it is actually being used by a vast majority of its users.
As an added benefit of refactoring an annoying bug in Buster will finally be addressed, and that is Buster's propensity to apply a file hash twice to a URL when it points to a file whose own name is in part used by another URL. For example, when hashing mybundle.js and mybundle.js.map Buster would ultimately hash mybundle.js.map as hash-hash-mybundle.js.map. This bug has long been a pain point and addressing it in this refactoring will be a very high priority.
If you are currently using Buster as a standalone utility and you aren't using it to cache bust "in place" then we sincerely apologize for any inconvenience these changes may bring you. However, it shouldn't be very difficult to refactor your own projects to use Buster's cache busting "in place" by simply directing your project's build process to generate its release files into a dedicated folder which then can be targeted by Buster to be cache busted "in place".
It is with great pleasure that I announce the release of Trio v5.0.0.
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).