Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://blog.nativescript.org/plugin-workspace-migrate-to-v2 below:

Migrate your plugin workspace in 2 seconds - NativeScript 8 + webpack5 + configuration updates

With one command you can auto update your plugin workspace for building with NativeScript 8, TypeScript 4.2, adjustments to configurations as well as auto updating your demo apps to use webpack5 setups.

Whether you are managing 1 plugin or a suite of 100, you can be working with the latest in seconds.

Back on September 14th, 2020, we introduced plugin workspaces to simplify and streamline maintenance on your NativeScript plugins. We hope you are using this plugin workspace seed to create NativeScript plugins today. On Github, there's a helpful green Use this template button which can be used to create one anytime.

There's been several nice additions and improvements with NativeScript since Sept. 14th, 2020 and you should enjoy them as well.

Here's why the plugin workspace approach matters:

nx migrate @nativescript/plugin-tools

That will result in the following at your terminal:

mac@user plugins % nx migrate @nativescript/plugin-tools
Fetching meta data about packages.
It may take a few minutes.
Fetching @nativescript/plugin-tools@latest
Fetching @nativescript/plugin-tools@2.0.0

>  NX  The migrate command has run successfully.

- package.json has been updated
- migrations.json has been generated

>  NX  Next steps:

- Make sure package.json changes make sense and then run 'yarn'
- Run 'nx migrate --run-migrations'

This will fetch the latest plugin-tools and adjust your package.json as well as add a migrations.json file. Running yarn will install the bumped version and then running the migrations will handle everything for you:

nx migrate --run-migrations

That one command will update your workspace in a matter of seconds to:

• NativeScript 8
• TypeScript 4.2.x
• @nativescript/webpack (webpack5)
• Adjust all demo app webpack.config's to use new webpack5 setups
• Adjust all demo app packages to use proper main
• Modify demo app tsconfig setups to match updates
• Adjust all plugins that have angular integrations to remove deprecation api's
• Update angular dependencies to latest v12
• Add proper polyfills for angular demo app
• Adjust demo-angular app main bootstrap to use new api
• Add a tsconfig to package angular harnesses to help angular type resolution
• Adjust workspace tsconfig to use the updated NativeClass transformer used with webpack5
• Update husky setup for improved auto code formatting on precommit
• Other nice little touches, etc.

Maybe you are into that sort of thing but does that really look like something you want to do on your own? Multiple times over across multiple repo's?

We believe developers prefer to focus on writing great NativeScript plugins; Not on laborous tasks to stay up to date with all the latest configuration improvements and advancements with NativeScript.

Depending on your coding style and package semantics there will always be a few manual touchups needed. For example, when moving from TypeScript 4.0 -> 4.2, Promise setups often need a proper generic defined.

To illustrate this, you might encounter an error like this when building after your migration:

packages/local-notifications/index.android.ts:101:5 - error TS2794: Expected 1 arguments, but got 0. Did you forget to include 'void' in your type argument to 'Promise'?

101     resolve();
        ~~~~~~~~~

  node_modules/typescript/lib/lib.es2015.promise.d.ts:33:34
    33     new <T>(executor: (resolve: (value: T | PromiseLike<T>) => void, reject: (reason?: any) => void) => void): Promise<T>;

Things like this are completely normal with TypeScript updates. The fix is quite simple. Inside packages/local-notifications/index.android.ts there was a method with this return type:

addOnMessageReceivedCallback(onReceived: (data: ReceivedNotification) => void): Promise<any> {

Since the Promise doesn't return a value, TypeScript is helping your code be more explicit about it's usage. Updating to the proper Promise return type resolves the issue:

addOnMessageReceivedCallback(onReceived: (data: ReceivedNotification) => void): Promise<void> {

Note the Promise<any> -> Promise<void>.

There's 2 new commands that were added with these updates to help you in managing your plugin (or suite of plugins).

1. The plugin seed comes with a vanilla and angular flavor demo. If you'd like to add others to try your plugins against different flavors you can do so easily now:

• npm run add-demo will prompt you for which additional demo flavor you'd like to generate (React, Svelte or Vue)

1. If you had added an experimental plugin or one you just simply want to remove:

• npm run remove-package will prompt you for which package you'd like to remove and will remove the package, it's configuration and all the shared demo files and demo flavor files associated with it.

yarn does a nice job with transient dependencies and is recommended when using workspace style developments that contain other dependency trees (like those of demo apps inside the workspace).

There's another improvement to plugin workspaces coming soon that will bring yarn workspaces in alongside Nrwl Nx to further improve the ease of maintenance for you so using yarn today will help ensure this subsequent improvement can help you in the near future.

We will be continually improving plugin workspaces over time with more conveniences via easy migrations to help you. We highly recommend them.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4