casamia918

/**
 * addLessLoader_forCRA5
 * customized addLessLoader of customize-cra for create-react-app@5.0.0
 *
 * CreatedAt : 2022-01-09
 *
 * Description: The customize-cra author copy getStyleLoaders codes from react-scripts@4.0.3 > webpack.config.js
 * But as react-scripts upgrade to version 5, they also upgrade postcss-loader, which causes change of options schema.
 * So, I re-copy getStyleLoaders codes from react-scripts@5.0.0 > webpack.config.js
 *

davistran86

import { catchError, map } from 'rxjs/operators';

const response = this.httpService
  .get('https://abc.com/api/v2/branches')
  .pipe(
    map((response) => response.data),
    catchError((e) => {
      throw new HttpException(e.response.data, e.response.status);
 }),

shadeglare

type Uuid = string;

sindresorhus

Pure ESM package

The package that linked you here is now pure ESM. It cannot be require()'d from CommonJS.

This means you have the following choices:

1. Use ESM yourself. (preferred)
   Use import foo from 'foo' instead of const foo = require('foo') to import the package. You also need to put "type": "module" in your package.json and more. Follow the below guide.
2. If the package is used in an async context, you could use await import(…) from CommonJS instead of require(…).
3. Stay on the existing version of the package until you can move to ESM.

awforsythe

{
    "name": "Forsythe",
    "author": "Alex Forsythe",
    "variables":
    {
        "base_bg": "hsl(0, 0%, 13%)",
        "base_fg": "hsl(0, 0%, 90%)",

        "highlight_fg": "hsl(40, 100%, 80%)",
        "highlight_fg_dim": "hsl(40, 80%, 70%)",

yuche

在 Taro Next 预览版（Alpha）版本之后，我们没有停下迭代的步伐，经过两个月的开发和数百次提交之后，现在我们谨慎但坚定地发布 Taro Next 测试（Beta） 版。相较于 Alpha，Beta 不但更稳定，也添加了更多的功能：

H5 编译支持

H5 编译支持是我们版本升级最重要的理由之一。这意味着原来开发者写的小程序应用，现在可以直接运行在 Web 中。添加 H5 支持非常简单，只需要在项目根目录安装 @tarojs/webpack-runner，运行 taro build —type h5 —watch 即可：

$ npm i -D @tarojs/webpack-runner@next
$ taro build —type h5 —watch

ZyqGitHub1

[
  {
    "id": "d240e1be-38aa-4356-88b8-d1febb48d95e",
    "name": "色色资源站",
    "uri": "https://www.emiao026.com",
    "httpApi": "http://sscj8.com/inc/api.php",
    "httpsApi": "http://sscj8.com/inc/sapi.php",
    "type": "综合性资源"
  },
  {

crapthings

version: '3'
services:
  mongo1:
    hostname: mongo1
    container_name: localmongo1
    image: mongo
    restart: always
    expose:
      - 27017
    ports:

cowlicks

const subscriptionMiddleware = {
  applyMiddleware: function(options, next) {
    // Get the current context
    const context = options.getContext().graphqlContext;
    // set it on the `options` which will be passed to the websocket with Apollo 
    // Server it becomes: `ApolloServer({contetx: ({payload}) => (returns options)
    options.authorization = context.authorization;
    next()
  },
};

bpartridge

So Hooks finally started to "click" for me when I realized they're very similar to Python decorators. In fact, they're essentially Python-like decorators, curried against the renderer, in an alternate syntax that reduces duplicate typing.

To be clear: I'm NOT advocating for Hooks moving towards decorator syntax, and I agree with the reasons why this suggestion isn't the right direction to move. But I think that the comparison with decorators is useful nonetheless, and perhaps could guide some of the ways in which we introduce Hooks to skeptical stakeholders.

Consider, for a moment, that Python almost adopted this syntax: https://www.python.org/dev/peps/pep-0318/#community-consensus ...

using:
    classmethod
 synchronized(lock)