I had React-Select version1 and recently had to upgrade to v2 since v1 would not support isMulti. But it caused a lot of issues like style changes and requiring 'value' attribute in the options and stuff. Those were fixed but when I pushed my code to dev server, realized, dev server has a lower node version that is not compatible with react-select V2. I do not have an option to upgrade node version. What would be the best alternative to have multiselect and no upgrade to react-select 2
Related
I'm maintaining a library (MyLib) published on npm that is a vuejs plugin. When I started this library, vuejs was at major version 2.x.x. vuejs now has a new major version 3.x.x that changed how plugins work.
Both 2.x.x and 3.x.x versions of vuejs are supported and will be for a while longer. I want my plugin library (currently version 5.x.x) to be available and supported for both.
Options I've seen or considered so far:
Have 5.x.x as the last version that supports vuejs#2 and 6.x.x and above for vuejs#3.
Easy enough
Doesn't allow me to release a new version with breaking changes that supports vuejs#2 ever if I follow semver rules.
Create a version 6.x.x of my library that supports both versions of vuejs.
Potentially possible, depending on the specifics.
Makes my library bloated because it needs to support both versions of vuejs and have (flaky) runtime version detection to choose the right code path.
Publish a separate library (e.g. MyLib-v2) that supports vuejs#3. Can possibly use a scoped package, but that would force users of 5.x.x of my library to change their dependency name with very poor discoverability.
Not sure how to manage this in a single repo. Monorepo?
Clunky, higher overhead
Is there a better way, or at least a not-awful way of managing publishing my library in this seemingly common scenario?
Use vue-demi. It lets you publish for both vue2 and vue3 in the same project. When using vue2, you have will access to the composition api as well.
https://github.com/vueuse/vue-demi
From the read me:
Vue Demi (half in French) is a developing utility
allows you to write Universal Vue Libraries for Vue 2 & 3
I am using Vue CLI to create a Vue 2.0 project and one of the options is using Babel. I understand Babel is a transpiler but what exactly does it do? I created a project with it and another without it and I don't see the difference so what exactly is the pro/con of it ? I can't see offhand what it is doing.
You are correct. Babel is a transpiler. It transpiles your JavaScript code to one or more taget browsers, that does not support the lastest fetures. You will not see any difference, if using a newer browser.
Babal usually only makes sense if you need to support older browsers, like IE 11 or browsers from before 2017.
I have installed Spartacus 3.2.2 recently. Can I please know is there documentation available to upgrade 3.2.2 to 3.3 ?
Can I please know if I upgrade to 3.3 will it effect to current development components or pages?
Upgrading to the later minor or patch version of Spartacus should not introduce any breaking changes to your application. It's because Spartacus follows the Semantic Versioning contract.
Sometimes new features introduced in minor versions of Spartacus might require some breaking changes, but in that case such features are not enabled by default. They will appear only when you opt-in to that feature by bumping the feature level in the Spartacus config. You can also opt-in to use the latest SCSS styles, by bumping the styles feature level variable in SCSS.
Significant breaking changes can be introduced only in major version. To smooth the migration process for you, Spartacus team provides the migration docs and automated migration tools (aka. schematics) that will fix some of the the breaking changes in your code and put code comments in your codebase near the usages of the changed Spartacus API.
For example, here are docs for migration from 2.x to the major version 3.0: https://sap.github.io/spartacus-docs/updating-to-version-3/
what is the best practice to upgrade the dependency v-calendar from beta to the latest version v2.3.0?
I know the question is opinion based, but I am new to the field, what are the pros and cons of the way to do the upgrade.
We use "v-calendar": "~1.0.0-beta.14" in production. The latest version is currently v.2.3.0
I can think of two ways:
update to the latest version with yarn add v-calendar#latest?
upgrade incrementally until the latest version is reached with yarn upgrade "v-calendar"?
What should I do to reach the latest version? thank you
ps. we are using vue: ~2.6.10
Unless the package you are using has an upgrade guide (99.99% of them don't), there is absolutely no point in doing an incremental upgrade. If it has an upgrade guide, read and follow its instructions.
The easiest way to upgrade is to change the package version to latest (in most IDE's if you press Ctrl/Cmd and hover the package number shown in package.json a tooltip will show you currently installed version, latest wanted version and latest available version). After you changed it (by typing the latest version in), run yarn install.
In the vast majority of cases, that's all you need to do, because most packages are built with backwards compatibility (existing features remain and new features are being added). If that's not true in your case, you'll have to reimplement it following their documentation. Typically it's no big deal.
Also, note there is no risk in attempting to change to a newer version. If things break, you just go back to package.json, change version back to lower, run yarn install again and everything is back to square one.
What is the best testing framework and its associated helper libraries to use for a project in React and JSPM? I'm looking for various libraries combined together and what is specific to that set which makes it a powerful toolset? (Looking to incorporate redux later on)
I recently build testing environment for a react application using JSPM.
I first wanted to use Jest, as it is recommended by the community with react. But then I found out that thread, saying support for JSPM/SystemJs wasn't on the roadmap at the moment.
Although it exists some work to make it work, see for example: https://www.npmjs.com/package/systemjs-jest
Then I chose to use Jasmine as it is quite known in my company, and I already worked with it.
Also I think Jest used to be based on Jasmine, so many react-specific matchers developed for Jest are also compatible with Jasmine.
So I ended up using Jasmine with Karma, using karma-jasmine and karma-uiuxengineering-jspm.
Make sure to read the documentation of karma-uiuxengineering-jspm thoroughly, it took me some time to set the environment up.
Some nice additions:
- jasmine-enzyme (installed with JSPM)
- karma-mocha-reporter (installed with npm)
- karma-phantomjs-launcher (installed with npm)