I have an umbrella project with 3 apps: main_web, main and child.
I have a macro defined in main which the child app uses.
When compiling, I sometimes get an error saying that Main.MyMacro is not defined in some_file_in_child_app.ex when I run the same command again, everything is fine.
I think this is from some_file_in_child_app.ex trying to use the macro before it has been compiled.
What is a good way to go about ensuring Main.MyMacro is loaded and so that I can avoid this error?
I'm not sure if going down the lines of running mix compile apps/main is the right way to go
If you have dependencies between your umbrella applications, you need to explicitly list them.
You should add this to apps/child/mix.exs:
def deps do
[
# ... other deps ...
{:main, in_umbrella: true}
]
end
Now Mix will make sure to compile main before compiling child.
Related
I'm converting a project that was built using Create React App to use ParcelJS as a bundler instead. Strangely, a dependency that I imported during development (#twilio/voice-sdk) works fine in the CRA version of the application, but I get the following error when I try to invoke the constructor in the Parcel version:
TypeError: (this._options.AudioHelper || audiohelper_1.default) is not a constructor
The package is identical between both (#v2.1.1, the latest). I'm importing using ESM syntax, so:
import { Device } from '#twilio/voice-sdk'
I trying using CommonJS syntax (require) and it still didn't work. I've dug into the compiled code, and that seems to be the issue. I imagine there are a lot of differences, but one that I've noticed is here:
On the left is the code compiled by Create React App, which does seem to be exporting something more substantial than on the left - is the export just an empty object? If so, it's no wonder I'm getting a constructor error.
Unfortunately, no amount of googling and SO sleuthing has clarified what I could do to make ParcelJS transpile this dependency properly, if that's the issue. I've tried to make the babel config for ParcelJS match CRA more closely by adding the following to a babel.config.json
{
"plugins": [
"#babel/plugin-transform-modules-commonjs"
]
}
But no luck. Any ideas from where to go from here, or is it time to switch to Webpack?
It looks like Twilio package has a problem when using Parcel 2: https://github.com/twilio/twilio-voice.js/issues/101
Say I develop a package with a limited set of dependencies (for example, LinearAlgebra).
In the Unit testing part, I might need additional dependencies (for instance, CSV to load a file). I can configure that in the Project.toml all good.
Now from there and in VS Code, how can I debug the Unit tests? I tried running the "runtests.jl" in the debugger; however, it unsurprisingly complains that the CSV package is unavailable.
I could add the CSV package (as a temporary solution), but I would prefer that the debugger run with the configuration for the unit testing; how can I achieve that?
As requested, here is how it can be reproduced (it is not quite minimal, but instead I used a commonly used package as it give confidence the package is not the problem). We will use DataFrames and try to execute the debugger for its unit tests.
Make a local version of DataFrames for the purpose of developing a feature in it. I execute dev DataFrames in a new REPL.
Select the correct environment (in .julia/dev/DataFrames) through the VS-code user interface.
Execute the "proper" unit testing by executing test DataFrames at the pkg prompt. Everything should go smoothly.
Try to execute the tests directly (open the runtests.jl and use the "Run" button in vs-code). I see some errors of the type:
LoadError: ArgumentError: Package CategoricalArrays not found in current path:
- Run `import Pkg; Pkg.add("CategoricalArrays")` to install the CategoricalArrays package.
which is consistent with CategoricalArrays being present in the [extras] section of the Project.toml but not present in the [deps].
Finally, instead of the "Run" command, execute the "Run and Debug". I encounter similar errors here is the first one:
Test Summary: | Pass Total
merge | 19 19
PASSED: index.jl
FAILED: dataframe.jl
LoadError: ArgumentError: Package DataStructures not found in current path:
- Run `import Pkg; Pkg.add("DataStructures")` to install the DataStructures package.
So I can't debug the code after the part requiring the extras packages.
After all that I delete this package with the command free DataFrames at the pkg prompt.
I see the same behavior in my package.
I'm not certain I understand your question, but I think you might be looking for the TestEnv package. It allows you to activate a temporary environment containing the [extras] dependencies. The discourse announcement contains a good description of the use cases.
Your runtest.jl file should contain all necessary imports to run tests.
Hence you are expected to have in your runtests.jl file lines such as:
using YourPackageName
using CSV
# the lines with tests now go here.
This is a standard in Julia package layout. For an example have a look at any mature Julia such as DataFrames.jl (https://github.com/JuliaData/DataFrames.jl/blob/main/test/runtests.jl).
I'm trying to migrate to Dart 2, I have a lot of packages and up to now I could do my job with not so much problems.
Now I'm getting a strange error bot with DDC and dart2js:
[SEVERE] build_web_compilers|entrypoint on web/main.dart (cached):
Unable to find modules for some sources, this is usually the result of either a
bad import, a missing dependency in a package (or possibly a dev_dependency
needs to move to a real dependency), or a build failure (if importing a
generated file).
Please check the following imports:
`import 'package:ledger_web/src/ui/components/main_selection_bar.template.dart';` from ledger_web|lib/src/ui/components/service/main_selection_bar_service.dart at 7:1
`import 'package:ledger_web/src/ui/components/main_selection_bar.template.dart';` from ledger_web|lib/src/ui/components/service/main_selection_bar_service.template.dart at 11:1
... and more
It is correct to signal that there is not the import (MainSelectionBar is an angular component), because the template has not been generated.
Now the problem is, why the template is not there?
I checked the .dart_tool/build/generated directory but the template has not been created.
I have a similar package with a similar component that works fine, so I cannot figure out what's happened.
Is there a place where there is a more detailed error list?
Interestingly enough, there is also a case in which the template exists, but it is listed like if it was not found....
Any hint?
Most likely this is related to a build failure when generating the template, which is not being properly reported on subsequent builds. This pull request should help that https://github.com/dart-lang/build/pull/1834/, but you can also try running pub run build_runner clean and then doing a new build to get the original error back.
I have a file called Parser.fs with module Parser at the top of the file. It compiles. I have another module in the same directory, Main, that looks like this:
module Main
open Parser
let _ = //do stuff
I tried to compile Main.fs with $ fsharpc Main.fs (idk if there's another way to compile). The first error is module or namespace 'Parser' is not defined, all other errors are because of the fact that the functions in Parser are not in scope.
I don't know if it matters, but I did try compiling Main after Parser, and it still didn't work. What am I doing wrong?
F#, unlike Haskell, does not have separate compilation. Well, it does at the assembly level, but not at the module level. If you want both modules to be in the same assembly, you need to compile them together:
fsharpc Parser.fs Main.fs
Another difference from Haskell: order of compilation matters. If you reverse the files, it won't compile.
Alternatively, you could compile Parser into its own assembly:
fsharpc Parser.fs -o:Parser.dll
And then reference that assembly when compiling Main:
fsharpc Main.fs -r:Parser.dll
That said, I would recommend using an fsproj project file (analog of cabal file). Less headache, more control.
I have a project that uses "coffee-script": "^1.7.1" in its package.json.
The code has this line in it:
[{id: id, name: name}, ...] = result.rows
This compiles fine using coffeescript version 1.7.1
The problem is that I am trying to use mocha for unit tests and it gives me an error on this line:
Parse error on line xyz: Unexpected '...'
Apparently mocha uses an older coffeescript. Is there a way to make it work without adjusting the source for mocha?
EDIT:
my Gruntfile.coffee:
'use strict'
module.exports = ->
#initConfig
cafemocha:
src: ['test/*.coffee']
options:
reporter: 'spec'
ui: 'bdd'
coffee:
compile:
files:
'lib/mylib.js': ['src/*.coffee']
#loadNpmTasks 'grunt-cafe-mocha'
#loadNpmTasks 'grunt-contrib-coffee'
#registerTask 'default', ['coffee', 'cafemocha']
I added mocha.opts to the test directory:
--require coffee-script/register
--compilers coffee:coffee-script/register
--reporter spec
--ui bdd
but, still, when I run grunt, it gives me the same error. I am new to this environment, and I find it too complicated, please help.
Starting from version 1.7.x CoffeeScript compiler should be explicitly registered (see change log for version 1.7.0).
So, the problem is that CoffeeScript compiler is not registered when you're running your mocha tests, so node.js treats all your .coffee files as .js files.
The best possible solution is to specify --compilers option for your mocha tests:
--compilers coffee:coffee-script/register
If you don't want to include it to every mocha call, you could set it up using mocha.opts file.
Here are some useful links:
issue about it on github
reference in mocha docs
the reason behind this breaking change in CoffeeScript engine
Update
Looks like your issue is much deeper then I thought.
First, grunt-cafe-mocha doesn't respect mocha.opts because it's running tests by requireing mocha as a dependency, instead of calling mocha test runner.
So, it would've been enough to add require('coffee-script/register') to the top of your gruntfile, if not for this old grunt issue.
In short, grunt uses coffee-script 1.3.x, forcing all its tasks to use the same version of coffee. I had the same problem with grunt-contrib-connect, being unable to use latest coffee-script in my express app.
So, the only help I can offer you is a small grunt task I wrote to solve similar problem in one of my projects. It runs mocha in a separate child process, thus completely isolating it from grunt.
N.B. I had a thought about releasing this task to npm, but considered it too minor.