Using MaterializeCSS with Webpack - Cannot resolve module 'hammerjs' - hammer.js

I'm building a project with webpack. The project uses materializecss. When I add materialize.js to the entry file, it complains with the error below
Cannot resolve module 'hammerjs'
When I open the file, I can see the definition there but it appears webpack is unable to identify it. Same thing with weakmap in knockout-es6. My solution to this was to add a reference to hammer.min.js in resolve.alias but not sure if that is the correct thing to do.
How do I get webpack to recognize these dependencies when they are bundled together with the library in question - in this case materialize.js?

As long as you have hammerjs installed to your project (ie. npm i hammerjs --save), it should find it. As pointed out by #egunays you should also have import 'expose?Hammer!hammerjs/hammer to get access to Hammer object.
In case you are worried about possible duplication (you can verify this by examining the generated bundle), you can use webpack.optimize.DedupePlugin. webpack.optimize.CommonsChunkPlugin can come in handy as well. That will allow you to separate your app code from a vendor bundle.
See official optimization docs for more info.

It's better to use ProvidePlugin for this.
new webpack.ProvidePlugin({
$: "jquery",
jQuery: "jquery",
"Hammer": "hammerjs/hammer"
}),
This does not require an extra loader and is actually recommended in the docs:
There are cases where you want a module to export itself to the global context. Don't do this unless you really need this. (Better use the ProvidePlugin) 1

Related

How do I use libproc.h in a modular Swift framework?

I've followed all the steps from other similar questions, and I'm still stuck.
I need to use the function proc_pidpath in libproc.h to get the path of a BSD process by its PID. However, libproc.h is not a modular header, so I can't include it in my umbrella header:
Fair enough; now I try to include it in my module map:
framework module My_Modular_Framework {
umbrella header "My_Modular_Framework.h"
private header "/usr/include/libproc.h"
export *
module * { export * }
}
Well now I get this error-vomit where it seems like it thinks many system modules/headers are within my project:
I can't figure out what else to do. Like I said, I already tried following all the steps of other similar questions without any success. What can be done here? How can I use proc_pidpath? Is there another, more Swift-in-modular-framework friendly way to get a path from a process ID?
I don't want to enable "Allow Non-modular Includes In Framework Modules" because that defeats the purpose of a modular framework.
Since libproc.h and libproc.c are open-source (APSL 2.0) as a part of Apple's Darwin project, you can just include them (under the terms of the license, of course) in your project. Since neither imports any non-modular headers, you can compile it yourself and the compiler won't complain!

define webpack internal paths to debug site with two bundles with similar file structures

I have a site that is using multiple independent webpack bundles, which all have roughly the same file structure. When I try to debug something in chrome devtools, it looks like modules are interefering with eachother on the debug level, since both use paths like webpack:///./src/index.ts, hence I'm only able to view the index.ts file of the last module loaded.
Is there a way to add a prefix or otherwise regulate the internal paths webpack is using? So that it becomes something like webpack:///[mymodulename]/src/index.ts
I found the solution, the following makes sure source maps use a relative filepath, and in this way I'm able to append something to it, so now I can debug each bundle individually again
output: {
filename: "./bundle_a.js",
devtoolModuleFilenameTemplate: "bundle_a/[resource-path]"
},

How to resolve import/no-unresolved errors with ESLint?

I've a project on Webpack that I'm trying to setup SASS transpiling with. I believe I am fairly close, although there are issues with my configuration (code and details in the gist here).
Running webpack with the code as it is yields the following error:
/foobar/src/js/components/App.jsx
6:8 error Unable to resolve path to module '../../scss/components/app' import/no-unresolved
Having spent a while on this, I noted that if I replace the import 'scss/components/app' line in App.jsx with import '../../scss/components/app.scss', the transpilation works. This leads me to believe that there are two issues:
My resolve.root Webpack configuration isn't working since relative imports work, but not absolute ones.
My resolve.extensions Webpack configuration isn't being applied either, since I need to append the .scss file extension to get it working.
Other notes:
I'm using webpack 1.13.1.
If I intentionally introduce syntax errors into the SCSS file, webpack correctly prompts me of issues with that file.
I've also tried setting my resolve.root configuration as an array (i.e. [path.resolve(__dirname, './src')]) to no avail.
Goal-wise, I'm hoping to achieve something similar to this example.
I've tried debugging the import paths with console-loader and am getting undefined.
Any help will be appreciated, thanks!
UPDATE:
A friend just shared that the issue is coming not from sass-loader/etc., but from eslint. This means the nature of this question is going to be quite different (less webpack, more eslint).
Anyway, my .eslintrc extends that of AirBNB's, I'm guessing I need to modify it based on the details in this plugin.
The part of interest is:
settings:
import/ignore:
- node_modules # mostly CommonJS (ignored by default)
- \.coffee$ # fraught with parse errors
- \.(scss|less|css)$ # can't parse unprocessed CSS modules, either
I've updated my .eslintrc to resemble:
{
"extends": "airbnb",
"settings": {
"import/ignore": [".scss$"]
}
}
But am still getting errors. Any ideas?
Can you post all the files in the gist? I tried looking for issues just by looking at the code but a runnable example with all files and imports in webpack config would be more helpful.
I'm curious why you added eslint to loaders instead of preloaders. You need to add it to preloaders.

Utility Classes In Ruby on Rails

This is probably a stupid question, but I'm new to Ruby on Rails and I could use a little guidance. I want to have a helper/utility class that performs a group of network operations and returns results. Where do I put that class and how do I use it.
I've created network_helper.rb in my app/modulename/helpers directory. In my controller when I try to do
myNetworkHelper = ModuleName::NetworkHelper.new
results = myNetworkHelper.getResults
I get an error
undefined method `new' for MyModule::NetworkHelper:Module
I'm sure this is just a misunderstanding of how ruby on rails works. Can I get some clarification?
Would it be better to make this a class instead of a module and put it in libs? And can I add subfolders in libs and have them automatically loaded?
Lib or Classes
Little utility classes like this typically go in the lib folder, though some people prefer to create a folder called classes. Whichever you choose, make sure you import the folder in config/application.rb, as the lib folder is not autoloaded:
config.autoload_paths += %W(#{config.root}/lib)
Concerns
If instead of a utility class, you want to extend some of your models with reusable code, you may also wish to look at the new Rails 4 concerns folders which encourage you to extract reusable modules:
see: How to use concerns in Rails 4
To use new, the thing your calling it on must be a class, not a module. You're using a module. Change module to class in lib/utilities/network_utility.rb.
I cannot verify this at the moment, however I believe one place you can store your custom modules and classes is the lib directory. Alternatively, you should be able to store them in the app directory in the manner you have indicated by adding the following line to your environment.rb:
config.load_paths << File.join(Rails.root, "app", "modulename")
Also, check out Yehuda Katz's answer, which I think not only answers your question better, but also contains some very interesting and useful information and concepts relating to your situation. Hope that helps!
Add your class to app/lib folder instead of lib, so that you don't change autoload paths!
Explanations:
The accepted answer suggests adding the classes to lib.
But according to this discussion:
The lib folder does not belong to the autoload paths since Rails 3.
So it's discouraged to add lib under autoload path. Use app/lib instead.

Building a plugin system for a nodejs based MVC platform

I would like to be able to build functionality for my application in a plugin style system for a couple reasons:
New projects can choose which plugins are necessary and not have code for functionality that's not needed
Other developers can build plugins for the system without needing too much knowledge of the core workings.
I'm not really sure how to go about implementing this. I would like to have a plugins folder to host these separately but I guess my questions are:
How do plugins interact with the core system?
How does the folder structure work? Would each hold the standard MVC structure: controllers, services, models, views, etc?
I guess if anyone has a tutorial or some documentation relating to this technique that would be helpful. I've done a bit of searching but it's all a little too closely related to the actual code they're working with instead of the concept and I hadn't found anything specifically related to nodejs.
I suggest an approach similar to what I've done on the uptime project (https://github.com/fzaninotto/uptime/blob/master/app.js#L46):
trigger application events in critical parts of your application
add a 'plugins' section in the applicaition configuration
each plugin name must be a package name. The plugin packages should return either a callback, or an object with an init() function.
either way, inject to the plugins the objects they will need to run (configuration, connections, etc) when calling init(), or executing the callback.
plugin modules register listeners to the application events and modify it
Benefits:
lightweight
rely on npm for dependencies
don't reivent the wheel
Create a plugin prototype for the base
functionality, and let the user define its plugin in a module. In the
module the user would inherit an object from the prototype, extend its
functionality, and then export a constructor which returns the plugin
object.
The main system loads all plugins by require("pluginname") and for
each calls the constructor.

Resources