Serenity 6.2.1 - 6.2.4 Release Notes (2022-10-11)
Fixed DefaultSqlConnections Null Reference Exception Causing Sergen to Fail (6.2.1)
We added logging support in 6.2.0 to Sql methods, but as logging via dependency injection is not available in Sergen environment, and we missed a null check in DefaultSqlConnections, sergen command was failing.
Recreated package-lock.json
File While Building VSIX Template (6.2.2, StartSharp)
We normally have a directory reference to corelib
in our package.json
during development:
{
"name": "startsharp.web",
"dependencies": {
"@serenity-is/corelib": "file:../../Serenity/src/Serenity.Scripts/corelib",
This allows us to test our changes in corelib
without having to publish an npm package, directly from the Serenity
submodule in StartSharp
.
During packaging of VSIX template, an automated process updated this dependency to the latest version of corelib at npm:
{
"name": "startsharp.web",
"dependencies": {
"@serenity-is/corelib": "6.1.4",
But as this does not affect package-lock.json
, that still contains the folder reference.
We distribute package.json
and package-lock.json
together in the StartSharp template. So when someone creates a new project from our template, package-lock.json
still contained a folder reference.
This was causing npm to create a symlink to a non-existent folder instead of downloading corelib from npm.
This is now fixed as our automated process deletes the package-lock.json
and node_modules
folder after patching package.json
and running npm install
command after, so that users will get a valid package-lock.json
file.
If you created a project with StartSharp template between 6.1.0 - 6.2.1, you may need to update Serenity packages, delete package-lock.json
and node_modules
and run npm install.
Fix Modular Typings Restore for Package References in node_modules
Folders (6.2.2, StartSharp)
We had a target in Serenity.Pro.Coder
file which restores modular typings from package / project references to folders under node_modules
instantly in Visual Studio / during build.
This was a workaround to ship modular typing files with NuGet packages that can be used by TypeScript, as it can't find those files under user's nuget folders (which might change for every user / pc).
Due to an expression mistake in MSBuild target file, the typings for Serenity.Pro.Extensions package was 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
only.
If your project had reference to Serenity.Pro.Coder 6.1.0 - 6.2.1, you may need to update Serenity packages and delete node_modules
folder then run npm install
.
Moved RestoreTypings to Serenity.Net.Web
We had a RestoreTypings
target in Serenity.Pro.Coder
and common-features
that restores index.d.ts
files from NuGet package and project references to typings
folder for namespaced ones and to the node_modules\@serenity-is
folders for modular ones without having to run sergen restore
.
This meant, it only worked with projects that reference Serenity.Pro.Coder
package. We now moved that msbuild target to Serenity.Net.Web
package so that this feature can be used for other projects.
After updating Serenity.Net.Web
you may notice that even if you clear typings
folder while having Visual Studio open, the directories and files will be restored instantly.
If you don't want this feature for some reason, add this line to your project:
<PropertyGroup>
<RestoreTypings>false</RestoreTypings>
</PropertyGroup>
Fixed the Problem Causing Grids To Not Display Data in Serene After Updating to 6.1.x (6.2.4)
DataGrid.defaultRowHeight
and DataGrid.defaultHeaderHeight
values are undefined by default. This values are passed to the SlickGrid instance via getSlickOptions()
method of the DataGrid
class.
As we rewrote SlickGrid as SleekGrid
and made jQuery
an optional dependency, this caused an issue in Serene when you update Serenity
packages to latest versions.
We used Object.assign
in place of jQuery.extend
method to apply default SlickGrid options to the options you pass to the SlickGrid constructor. They are mostly compatible, but seems like there is a subtle but important difference between them.
While, jQuery.extend
skips properties that have undefined
value, Object.assign
does not. Thus, the undefined default row height passed from getSlickOptions
to the grid was overriding the SlickGrid default value.
We couldn't reproduce this issue in StartSharp because the premium theme sets DataGrid.defaultRowHeight
to compensate for the larger default font size.