In version 6.2.0, we introduced logging support for SQL methods. However, because logging via dependency injection is not available in the Sergen environment, and due to a missing null check in DefaultSqlConnections, the Sergen command was failing.
During development, we usually reference the corelib directory in our package.json as follows:
{
"name": "startsharp.web",
"dependencies": {
"@serenity-is/corelib": "file:../../Serenity/src/Serenity.Scripts/corelib",This allows us to test changes in the corelib without the need to publish an npm package, directly from the Serenity submodule in StartSharp.
When packaging the VSIX template, an automated process updated this dependency to the latest version of corelib on npm:
{
"name": "startsharp.web",
"dependencies": {
"@serenity-is/corelib": "6.1.4",However, this change did not affect the package-lock.json, which still contained the folder reference.
We distribute both package.json and package-lock.json together in the StartSharp template. Therefore, when someone created a new project from our template, the package-lock.json still contained a folder reference.
This caused npm to create a symlink to a non-existent folder instead of downloading corelib from npm.
To address this, our automated process now deletes the package-lock.json and node_modules folder after updating the package.json and running the npm install command. As a result, users will receive a valid package-lock.json file.
If you created a project using the StartSharp template between versions 6.1.0 and 6.2.1, you may need to update the Serenity packages, delete the package-lock.json and node_modules, and then run npm install.
Fixed Restoration of Modular Typings for Package References in node_modules Folders (6.2.2, StartSharp)
In the Serenity.Pro.Coder file, we had a target to restore modular typings from package or project references to folders under node_modules. This restoration occurred instantly in Visual Studio or during the build process.
This feature was implemented to provide a workaround for shipping modular typing files with NuGet packages that TypeScript can use. TypeScript might not locate these files under users' NuGet folders, which can vary between users or PCs.
Due to an expression mistake in the MSBuild target file, the typings for the Serenity.Pro.Extensions package were being restored to an invalid folder like node_modules\@serenity-is\pro.extensions;@serenity-is\pro.extensions, instead of node_modules\@serenity-is\pro.extensions as intended.
If your project had a reference to Serenity.Pro.Coder between versions 6.1.0 and 6.2.1, you may need to update the Serenity packages, delete the node_modules folder, and then run npm install.
We previously had a RestoreTypings target in both Serenity.Pro.Coder and common-features. This target restored index.d.ts files from NuGet package and project references to the typings folder for namespaced ones, and to the node_modules\@serenity-is folders for modular ones. This restoration was achieved without needing to run sergen restore.
However, this feature only worked for projects that referenced the Serenity.Pro.Coder package. To expand its usability to other projects, we have moved this MSBuild target to the Serenity.Net.Web package.
After updating Serenity.Net.Web, you may notice that even if you clear the typings folder with Visual Studio open, the directories and files will be restored instantly.
If you wish to disable this feature for any reason, add the following line to your project file:
<PropertyGroup>
<RestoreTypings>false</RestoreTypings>
</PropertyGroup>The DataGrid.defaultRowHeight and DataGrid.defaultHeaderHeight values were originally undefined by default. These values are passed to the SlickGrid instance via the getSlickOptions() method of the DataGrid class.
With the rewrite of SlickGrid as SleekGrid and the optional dependency of jQuery, a problem emerged in Serene when updating Serenity packages to the latest versions.
In this update, we replaced jQuery.extend with Object.assign to apply default SlickGrid options to the options you provide to the SlickGrid constructor. These methods are mostly compatible, but a subtle yet important difference exists between them.
While jQuery.extend skips properties with undefined values, Object.assign does not. Consequently, the undefined default row height passed from getSlickOptions to the grid was overwriting the SlickGrid default value.
It's worth noting that this issue did not reproduce in StartSharp because the premium theme set DataGrid.defaultRowHeight to compensate for the larger default font size.