Is there any tutorial for the scripted plugin? Or maybe a new way to test plugins. I've found a tutorial that seems to be a bit old.
If I have to resort to Scripted, some questions that come to my mind:
Do I need to publish local my plugin before running scripted?
Can I refer to the version located in version.sbt from my tests?
For the record, I'm also using the cross-build plugin, so if possible, the tests would need to cover both 0.12 and 0.13 versions.
(Author of the linked testing sbt plugins here) There hasn't been major changes to scripted since I first wrote it, but I updated some of the details.
To test the plugin end-to-end, publishing locally I think makes sense.
See the updated post. You can pass version number as a property using scriptedLaunchOpts, and catch it with System.getProperty on the other side.
Eugene's answer is still relevant, but now, Sbt Plugins Testing has a proper documentation page in the official sbt documnetation site:
http://www.scala-sbt.org/release/docs/Testing-sbt-plugins.html
Related
I'm looking to install Webpack4 for a project.
Part of what I want it to do is lint css.
Just about every resource I find points to "stylelint-webpack-plugin" (https://github.com/JaKXz/stylelint-webpack-plugin).
That project's not been getting updated for a long time.
From what I can tell the webpack team bullied the dev responsibile for lots of the work on stylelint-webpack-plugin right out of the community.
So now the project's got nobody doing the work and it's "looking for a maintainer". After that whole mess, doesn't look like anyone's signing up.
From my perspective -- Oh Well! Next !?
Is there a different alternative to stylelint-webpack-plugin for lint-ing styles in a webpack setup?
The stylelint-webpack-plugin now belongs to the official webpack-contrib GitHub organisation. The plugin's dependencies are up-to-date and it supports the latest version of stylelint (version 9).
I believe it is the still the most appropriate plugin for using stylelint within Webpack.
I just accidentally refactored QList to QSet, and Qt faithfully did it, to all of its own sources too... (yup, that was dumb!)
Thankfully my code is source controlled, I just reverted everything, would it be feasible/sensible to make a git repo for the Qt sources too? (I have the free version so I didn't think I could modify them anyway...?)
Is there a hidden setting that will prevent its sources from being modifiable, to stop me from doing this again?
I'm currently using the maintenance tool to install a newer version of Qt, but other than update or add/remove, there wasn't a re-install option that I could see, am I missing something?
There's no point to using source code control for an install: it's not source code. It's artifacts. You already know how to protect artifacts of all sorts from modification. Proper filesystem attributes will do it just fine.
Your finished Qt installation should not be writable by you. It would be by default on Unix systems when installed using a privileged package manager. Elsewhere: you need to make it read only. If you build from source, then recursively making the install folder read-only as the last step after installation is all it takes; and since you should be already automating your Qt build, then adding the "make read-only" step is trivial.
Thankfully my code is source controlled, I just reverted everything, would it be feasible/sensible to make a git repo for the Qt sources too? (I have the free version so I didn't think I could modify them anyway...?)
Feasible? Definitely. Sensible? Perhaps, assuming that by "make a git repo" you mean "cloning the official Qt repos from Git". It depends on how many times you plan on making the same renaming mistake. :D But seriously, I think there are benefits to building Qt yourself:
You can easily debug and check the implementation of API that you're using.
You can configure Qt to skip building stuff that you're not interested in.
You can easily patch Qt if there's a bug that you know of a fix for but hasn't been merged into Qt itself yet.
There are downsides too, though. You might run into build issues if you're using configure flags that the CI doesn't use (such as a -no-foo option). It can take a while to build depending on how many submodules you have and what kind of machine you're building on.
In general, if you're not using API that's in dev and not yet released, it's probably not worth bothering.
If you're still interested, this page has instructions for building Qt from Git:
https://wiki.qt.io/Building_Qt_5_from_Git
Is there a hidden setting that will prevent its sources from being modifiable, to stop me from doing this again?
Couldn't you set some permissions on the source directory? I've never had to do this, but have been bitten by it on unrelated occasions before, so I know it works. :D
I'm currently using the maintenance tool to install a newer version of Qt, but other than update or add/remove, there wasn't a re-install option that I could see, am I missing something?
Remove and add is your only option, I think. Otherwise, you can always keep a backup of the source by just copying the whole directory.
I use scalafmt plugin in my project, also I use scalafmt plugin for Intellj in order to format my Scala code.
Usually I use hot keys or run sbt scalafmt to formatting.
sbt.version=1.0.3
addSbtPlugin("com.geirsson" % "sbt-scalafmt" % "1.3.0")
Question:
Any advice how can I format code with scalafmt automatically on compile time?
UPDATE: just update the plugin version and use
scalafmtOnCompile := true
The answer below is outdated, it recommended using an alternative plugin, but now it's another way round, the official one is up to date and supports this feature out of the box.
From the scalafmt installation instructions for the plugin your use:
The sbt plugin does not provide reformat on compile settings. This gist shows a DIY plugin to enable reformat on compile. YMMV.
Why isn't that gist included in the sbt plugin? See #597.
I recommend you to try neo-sbt-scalafmt instead. It's generally more configurable and better maintained (the other plugin is abandoned, see the issue linked above). With this plugin you can turn on formatting on compilation with simple
scalafmtOnCompile := true
See docs for more options.
I would like to know where can i find or whats the official process to consider when you have to update both the modules and the core in a Drupal 7 site at same time.
I mean, what do i have to update first?
Modules then Core, Core then modules or it doesn't matter at all or it depends of each module documentation?
Also i would like to know if this process changed in Drupal 8.
I have found the process to update each one but not together.
I always do modules then core, but if you have a good reference or any article with a justification for this will be better to understand why.
Thanks in advance
Firstly I would suggest you to use drush commands to upgrade core version. It will take care of the rest. But if you want to do manually then you can continue reading below answer.
In my opinion you have to update the core first ( if there is latest core and the core required modules available ) and then you can update other modules i.e contrib modules. At the end custom modules based on compatibility.
After placing the latest code you can use drush updb or {your domain}/update.php to update your database.
Or else you can do it in the following way:
Download latest drupal code, place your custom code inside it and use the old database and then run update. This is not the correct way but sometimes it works.
Note: Before doing any of the steps above always work in local environment and keep a backup. Never try it on production.
Thanks
Can I just replace the two old version realm frameworks to the new version ones? Or what should I do?
Yep! If you're not using a dependency manager like CocoaPods or Carthage, you just need to delete the old framework folders and copy the new ones into the same place. Xcode should be fine handling that the next time you attempt to build your project.
If you are using a dependency manager, then you just need to hit the update command in their command line tools, and it'll be taken care of automatically.
Please keep in mind that Realm 0.97 has completely removed all of its previously deprecated APIs, so if you were using any of those, you will get build errors, but they'll be very easy to fix.
I cam up with the same question and while looking around came up with a good solution. This is in addition to what TiM has pointed out. Also, a few things to keep in mind:
I upgraded from version 1.0 to 1.0.1: so there weren't many changes to the framework and commands I used in my app.
I didn't use any special or very specific commands. Mainly the queries and writes/updates of objects. Nothing very fancy. If you have very specific requirements of Realm than I suggest look into those and see if there are any special changes to how they are managed.
Now to the steps:
Remove the frameworks from the "Embedded Binaries" section by clicking the "-":
General Tab - Embedded Binaries
Remove the frameworks from the project itself by right-clicking on them and select "Delete"
Navigator - Framework Files
Now just go and do the steps for installing the frameworks as found in the documentation "realm.io/docs/swift/latest/#installation-swift-22".
I understand this question is rather old, but looking through the SO I dint find a definite answer to this.
Hope this helped!