I want to make use of new APIs in sinon-4 (which is already pretty dated per se but still), but when I try to use it, it breaks the test due to incompatibility with sinon-qunit. What's the use of sinon-qunit exactly? Can I safely remove it?
P.S. I tested by upgrading to sinon-4 and removing sinon-qunit at all places, and all unit tests worked as usual.
Related
I have seen some old questions/answers that said it's impossible to create a type alias on Flutter. I just want to make sure whether it's the case, as the language seems to have been updated numerous times since.
My specific question is, how can I make a type alias like this:
typealias Json = Map<String, dynamic>;
?
Or is there any workaround, because I've tried to use empty mixin to do this but it says that there are 18 missing method implementations.
Small update on Randai Schwartz's comment.
The feature seems (as of April 2021) almost ready and will probably be released in the next minor version or the one after it.
When you read this, it is probably worth checking the following issue:
https://github.com/dart-lang/language/issues/65
This should allow to do:
typedef NewTypeName = OldTypeName;
Update:
Flutter officially supports now typedefs. :)
So you can just use my code example above.
At this point, typedefs are supported only for Function types (https://dart.dev/guides/language/language-tour#typedefs). There is talk of adding more, but not any time soon (https://github.com/dart-lang/language/issues/115).
Flutter 2.2 has been released together with Dart 2.13, now SimonEritsch code should work as you wanted as long as you run flutter upgrade on your terminal or upgrade your dart.
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.
just out of curiosity:
As you all might or might know, it is possible to set a custom BE logo with $GLOBALS['TBE_STYLES']['logo'] = '../fileadmin/mylogo.png'; in typo3conf/extTables.php.
This behavior is working since old v4.x times.
But I just read that extTables will be deprecated in v8.x.
I tried to find a simple solution to this (one that keeps that one-line simplicity and does NOT require me to create&install an extension!)
I moved this line to typo3conf/AdditionalConfiguration.php,
but it does not work from there.
Why?
What would be necessary to make this line work within typo3conf/AdditionalConfiguration.php ?
In TYPO3 8.x you'll be able to change a backend logo via EXT:backend, so you should stick to that approach. Read more in release notes.
UPDATE.
To answer your question, why TBE_STYLES defined in AdditionalConfiguration are ignored: take a look at unsetReservedGlobalVariables() method from \TYPO3\CMS\Core\Core\Bootstrap class. It is executed after all the configuration is initialized (Local and Additional are merged and populated) and explicitly calls unset($GLOBALS['TBE_STYLES']);.
I'm writing a small library which I'd like to be backwards compatible with older versions of an API, yet use features of the latest API when possible.
So for example, I have a project which uses an external API, which I'll call FooFoo_v1.
Initially, my code looked like this:
// in Widget.scala
val f = new Foo
f.bar
Foo has since released a new version of their API, FooFoo_v2, which adds the bat method. So long as I'm compiling against the new version, this works fine:
// in Widget.scala
val f = new Foo
f.bar
f.bat
But if you try to build against FooFoo_v1, the build obviously fails. Since the bat feature is truly optional, and I'd like to allow folks to build my code against FooFoo_v1 or FooFoo_v2.
Ignoring the details of the dependency management, what's the right high level approach for something like this? My aim is to keep it as simple as possible.
I think you should split your library in two pieces - one with features used from FooFoo_v1, another depending on the first one and on FooFoo_v2 and using features from FooFoo_v2. How to accomplish it depends on your code... If it's too difficult it's better to follow #rex-kerr advice - to maintain two branches.
I would simply keep separate branches of the project in a repository (one which is sufficiently robust to allow you to edit one and merge effortlessly into the others--git would be my first choice).
If you must do the selection at runtime, then you're limited to using reflection for any new methods.
I'm working on a very large CGI application that uses Crypt::RSA, which is properly installed. I get a "attempted to call a null reference as a function" type of error (I can't go back to get the exact error right now because we had to rollback for a release date) when I try to run any the embedded library. I trace the null reference to Crypt::RSA's constructor, which uses Class::Loader to enable Crypt::RSA::ES::OAEP.
I replaced the class loader with a "use" and a "new", and that part works fine, though the library still fails in many points. Obviously something is wrong with my environment. I'm just not certain as to what. Can anyone give me any leads?
Ok, after 12 hours of digging into it, I got this working.
Here's what was going on (but not why). Whenever I called eval() on a quoted use or require statement (as occurs in Class::Loader, but also in other locations in the Crypt:: framwork), it failed to see paths that were otherwise included as Perl classpaths. Since most quoted use/require objects simply assume the class will be there, very few useful errors were thrown out at me. I would dump #INC to file, outside an eval block, and everything would be there.
Ironically, I used the same setup in dev vs staging, and it worked in dev, but not in staging. I must also point out that FindBin (I shouldn't be using it in CGI, I know, but Crypt uses it) was flailing up and down about /dev/null in staging, but not in development.
Since I can't easily compare versions or global configs, that's where my quest ends.
How I resolved the issue for myself in Crypt::RSA was to disable all commands tied to FindBin, and hard-code require references for anything my code would ever access. I did a require in Crypt::RSA for Crypt::RSA::ES::OAEP and one in Crypt::Random::Generator for Crypt::Random::Provider::rand
Hope this helps anyone in the future who has the problem. Anyone who can suggest the why of it, please respond and I'll add it to complete the post.