BUG? What happened to basePackage? Follow
Previously there was a basePackage option:
<option name="basePackage" value="cgta.olib" />
object under the scala facet for modules.
I am unable to find that since trying out the new version (which has broken other things as well).
Where is it located? I used to use gen-idea because it let me set it programmatically in the sbt file and then share that
setting with my entire team.
We have to have basePackage set on a per module basis because we expect that our package objects will be in scope,
if this isn't available then every new file is made with one package line at the top, instead of breaking the package line up properly,
which is obviously very frustrating and then causes compile errors for our projects.
This coupled with the broken import resolution is causing us issues in being able to move our team to the newest version of intellij.
I know you guys are busy but we have been waiting to get these issues (as well as proper scala js cross compilation support) fixed for a long time.
Please sign in to leave a comment.
The basePackage options were temporary hidden because of the total project configuration redesign (which is mostly complete now).
These options should not affect neither reference resoultion, nor project compilation (they apply only to newly created files).
Anyway, we're going to return these options soon (SCL-8360).
It does affect every single file we create or move, so it's pretty significant
locker for us since we rely on package objects to emulate a roll your own
So, while I understand it doesn't affect existing files it does break things
we rely on so it's a bug to us.
We cannot create files or move them without introducing errors into our codebase.
So I am sitting back on an old version and using gen-idea until this is supported.
Some of the other devs here don't create/move as often, however it's still very
annoying that they have to go up and manually chain the package clause
because this feature was removed with no warning.
This is on top of all local imports from companions being broken for months and
no update on a timeframe for a fix.
It seems as breaking features users rely on is viewed not as introducing bugs but rather
as introducing new feature requests. So functionality users are depending on will
stay broken until something get's implemented in the future at "meh that's just a
feature request," "hmm he should not have relied on that feature anyhow speed."
I understand that some users use the community edition, I started buying the Ultimate
intellij solely to support the great work being done Scala Plugin, however willy-nilly
breaking things I rely on and telling me it's not a big deal, is a big deal to me.
At some point installing the latest version of the Scala Plugin went from being excited
about more and more of scala being supported to being terrified that some developer
has decided to blindly break some feature and then refuse to consider that a bug that
needs to be urgently fixed.
While reading your answer I just realized how to close https://youtrack.jetbrains.com/issue/SCL-7841 in simple way. The idea is quite obvious, as local imports are most probably hand-written (IDE auto-import puts everything on top of file), so IDE shouldn't think that fully-qualified path for such imports is right thing (it's still ok to put local imports in lexicografical order). Fix will be available in EAP build, which I'm planning to release today.
Anyway sorry for all inconveniences, and thank you for being our user.
Thank you so much!
I am very happy to be an intellij user as you guys made such great strides
in making a useable IDE for Scala back when eclipse was unusable. Before that life
was pretty miserable: write Java and get great tooling or use scala and get a great
However even the early version of the intellij plugin tilted that balance in Scala's favor.
Things have steadily improved since so I guess I can take it for granted at times how
far things have come.
Restricting the fix to local imports isn't perfect for all of our use cases, our practice is
that things below the copyright notice (which is itself below the imports) are managed
by the programmers manually.
But it's close enough that it won't be a big deal to clean up the files that don't match and
this solution is possibly a more clear demarcation between which imports Idea owns
and which one the developer will be handling.
So thank you so much for fixing this!