Are #babel/runtime and #babel/plugin-transform-runtime supposed to be on the same version (e.g. both 7.2.0 exactly)? Or can I (as a library author) specify #babel/runtime dependency as ^7.0.0, whilst having the latest #babel/plugin-transform-runtime?
I'm aware that during the beta versions of Babel 7, there was a breaking change in beta.56 (see https://stackoverflow.com/a/51686837/2148762), but I'm guessing this should no longer be the case with the current stable version?
The reason I ask this is I'd ideally want the helpers from #babel/runtime to be shared across different packages, and to me leaving the version range open seems like a good idea. But at the same time, I'm not sure how low I should go (^7.0.0 or ^7.2.0), and whether there's an implicit contract between #babel/runtime and #babel/plugin-transform-runtime with regards to version numbers.
By default, #babel/plugin-transform-runtime is only allowed to output references to #babel/runtime that work on ^7.0.0 because it does not know what version you'd otherwise want to use, and doing anything else would cause lots of issues for users. This means that what you want to do is safe. The downside of this is that, if we add new helpers moving forward, your code would not be able to take advantage of the #babel/runtime version of them (because you might still be using a #babel/runtime version that doesn't have them.
Users can specify the version in the arguments for the transform, if you want to specifically make use of helpers that may have been added to Babel since 7.0.0, e.g.
{
"plugins": [
["#babel/plugin-transform-runtime", { version: "^7.2.0" }],
]
}
would then require you to have "#babel/runtime": "^7.2.0" in your package.json.
For instance, since support for the newer decorators proposal didn't land until Babel 7.1.5, if you use transform-runtime and non-legacy decorators, the decorators helper will still be inserted into every file where you use decorators, instead of importing it from #babel/runtime. To get the shared helper, you need to specify version: "^7.1.5" in your options for transform-runtime.
Can I (as a library author) specify #babel/runtime dependency as ^7.0.0, whilst having the latest #babel/plugin-transform-runtime?
Yes, this is safe.
I'm guessing this should no longer be the case with the current stable version?
Correct, that issue was because people failed to take the beta versioning into account.
Related
I am looking for potential pitfalls or best practices when supporting multiple TYPO3 major versions with extensions. There are some things to consider.
I noticed several extensions support several TYPO3 major version in one version, e.g.
extension version 1.0.0 supports 9.5.* and 10.4.*
However, this way, you can't really get rid of things as soon as they are deprecated. (For example, a function may be deprecated in 10 and there is a replacement function, but this is not available in 9, so in order to support both you use the deprecated function).
This has the disadvantage, that the extension scanner will point out lots of things which are just deprecated. I am a huge fan of the extension scanner and getting rid of deprecations as soon as possible.
When I created my extension migrate2composer I used a separate version branch 8.7. But this is more work if I fix bugs because it needs to be backported.
What is a good strategy and are there ways to keep the workload minimal?
One possibility to support multiple versions and already use the new functionality can be found in the bootstrap_package:
/***************
* Make the extension configuration accessible
*/
if (class_exists(\TYPO3\CMS\Core\Configuration\ExtensionConfiguration::class)) {
$extensionConfiguration = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(
\TYPO3\CMS\Core\Configuration\ExtensionConfiguration::class
);
$bootstrapPackageConfiguration = $extensionConfiguration->get('bootstrap_package');
} else {
// Fallback for CMS8
// #extensionScannerIgnoreLine
$bootstrapPackageConfiguration = $GLOBALS['TYPO3_CONF_VARS']['EXT']['extConf']['bootstrap_package'];
if (!is_array($bootstrapPackageConfiguration)) {
$bootstrapPackageConfiguration = unserialize($bootstrapPackageConfiguration);
}
}
The line // #extensionScannerIgnoreLine will make the extension scanner ignore the following line and will not clutter up the report with this, see Extension scanner documentation.
Thanks goes to Simon Gilli for pointing this out ...
I release a unique version for each TYPO3 LTS version to be able to throw out old stuff. This also facilitates automated testing.
I am like you using different branches to manage that and cherry-pick commits between them.
It's a little bit more work but can be facilitated with helper scripts. I have written some sentences about our reasoning here https://docs.typo3.org/p/dmind/cookieman/master/en-us/Contributors/Index.html#branches
I've heard from some users being confused by the versioning scheme, so in hindsight for the next time I would choose to stick with 1 major version = 1 TYPO3 LTS.
E.g. starting with
v1 - TYPO3 v9
v2 - TYPO3 v10
v3 - TYPO3 v11
And then if our extension has breaking changes, continue with the next free major version, maybe removing the "new feature" support for an older LTS.
v4 - TYPO3 v10
v5 - TYPO3 v11
It is also a compromise however. This way you cannot say that feature X is "in version > 4.1" but maybe the composer scheme will be better understood in the future so you could say "^4.1 || ^5.1".
babel-preset-env allows to automatically determine the needed polyfills and transformation but how does it check at runtime if the target versions specified at compile time are really available.
Let say I target safari 10 using
"targets": {
"safari": 10
}
but the code is run on an older version of safari.
How does babel-preset-env recognize this or what are the typical ways to deal with this common problem?
babel-preset-env does not carry out any runtime checks. It enables only the transforms that are required for your specified environment. You're effectively setting your minimum supported environment, and opting out of any transforms that would be required to support lower versions.
For example, if all of the browser versions specified in my config supported ES2015 classes, Babel would not transform classes into an ES5-supported form, since it's not necessary to do so!
I have a custom machine layer based on https://github.com/jumpnow/meta-wandboard.
I've upgraded the kernel to 4.8.6 and want to add X11 to the image.
I'm modifying to image recipe (console-image.bb).
Since wandboard is based on i.MX6, I want to include the xf86-video-imxfb-vivante package from meta-fsl-arm.
However, it fails complaining about inability to build kernel-module-imx-gpu-viv. I believe that happens because xf86-video-imxfb-vivante DEPENDS on imx-gpu-viv which in turn RDEPENDS on kernel-module-imx-gpu-viv.
I realize that those dependencies have been created with meta-fsl-arm BSP and vanilla Poky distribution. But those things are way outdated for wandboard, hence I am using the custom machine layer with modern kernel.
The kernel is configured to include the Vivante DRM module and I really don't want the kernel-module-imx-gpu-viv package to be built.
Is there a way to exclude it from RDEPENDS? Can I somehow swear my health to the build system that I will take care of this specific run-time dependency myself?
I have tried blacklisting 'kernel-module-imx-gpu-viv' setting PNBLACKLIST[kernel-module-imx-gpu-viv] in my local.conf, but that's just a part of a solution. It helps avoid build failures, but the packaging process still fails.
IIUC you problem comes from these lines in img-gpu-viv recipe:
FILES_libgal-mx6 = "${libdir}/libGAL${SOLIBS} ${libdir}/libGAL_egl${SOLIBS}"
FILES_libgal-mx6-dev = "${libdir}/libGAL${SOLIBSDEV} ${includedir}/HAL"
RDEPENDS_libgal-mx6 += "kernel-module-imx-gpu-viv"
INSANE_SKIP_libgal-mx6 += "build-deps"
I would actually qualify this RDEPENDS as a bug, usually kernel module dependencies are specified as RRECOMMENDS because most modules can be compiled into the kernel thus making no separate package at all while still providing the functionality. But that's another issue.
There are several ways to fix this problem, the first general route is to tweak RDEPENDS for the package. It's just a bitbake variable, so you can either assign it some other value or remove some portion of it. In the first case it's going to look somewhat like this:
RDEPENDS_libgal-mx6 = ""
In the second one:
RDEPENDS_libgal-mx6_remove = "kernel-module-imx-gpu-viv"
Obviously, these two options have different implications for your present and future work. In general I would opt for the softer one which is the second, because it has less potential for breakage when you're to update meta-fsl-arm layer, which can change imx-gpu-viv recipe in any kind of way. But when you're overriding some more complex recipe with big lists in variables and you're modifying it heavily (not just removing a thing or two) it might be easier to maintain it with full hard assignment of variables.
Now there is also a question of where to do this variable mangling. The main option is .bbappend in your layer, that's what appends are made for, but you can also do this from your distro configuration (if you're maintaining your own distro it might be easier to have all these tweaks in one place, rather than sprayed into numerous appends) or from your local.conf (which is a nice place to quickly try it out, but probably not something to use in longer term). I usually use .bbappend.
But there is also a completely different approach to this problem, rather than fixing package dependencies you can also fix what some other package provides. If for example you have a kernel configured to have imx-gpu-viv module built right into the main zimage you can do
RPROVIDES_kernel-image += "kernel-module-imx-gpu-viv"
(also in .bbappend, distro configuration or local.conf) and that's it.
In any case your approach to fixing this problem should reflect the difference between your setup and recipe assumptions. If you do have the module, but in a different package, then go for RPROVIDES, if you have some other module providing the same functionality to libgal-mx6 package then fix libgal-mx6 dependencies (and it's better to fix them, meaning not only drop something you don't need, but also add things that are relevant for your setup).
I am currently analysing movement data using the script provided by Lascelles et al (2016) in their paper "Applying global criteria to tracking data to define important areas for marine conservation". I have made some changes and additions to the script and now face the problem that the different packages needed do not work within the same version of R.
I am using the package "trip" which from what I can see works with >=3.2.5 but depends on spatstat which works with >=3.3.0. The script also uses the overlay function from the "sp" package, however this function has been deprecated, thus in order to run needs an older version of R (I have previously used version 3.0.3.
Is there a way to use multiple versions of R within the same project, or would I have to rewrite the script to avoid using functions that do not work within the same R version?
If you don't need any of the new functions/features introduced in the later versions of trip and spatstat I think you can just use the checkpoint package and install the versions from an earlier date. There is a nice vignette you can have a look at, but basically you just do something like:
install.packages("checkpoint")
library(checkpoint)
checkpoint("2016-01-01")
The MongoEnvironmentSetter#setLatencySmoothFactor method updates the system property com.mongodb.latencySmoothFactor and it isn't available since 2.12.0 ( related git hashes 0375c984fccf9cb0868b406c145f8fd3e263348c 1ae976fa2342cdddeade622f293dc3fccbb80a58). I found the following tickets related to that:
https://jira.mongodb.org/browse/JAVA-763
https://jira.mongodb.org/browse/JAVA-786
https://jira.mongodb.org/browse/JAVA-859
https://jira.mongodb.org/browse/JAVA-930
https://jira.mongodb.org/browse/JAVA-931
But I didn't find the equivalence to this property. Any thoughts? Which are the steps to do in a migration if some application has configured this property?
There is no equivalent in 2.12, as the driver no longer performs any smoothing of round-trip times. Smoothing may be added in a future release, but most likely it won't be configurable. I'm not sure what the MongoEnvironmentSetter is, but assuming this is something you control, your best option is to ignore that property or remove it.